I'm trying to start a dialogue with these comments where a clear description of core data relationships can be discussed.
I've been building relational databases for more than three decades, and I find it interesting that every database development environment that uses relationships has a problem in writing a clear and decisive method of using the relationships.
In Xcode, things are no different where the descriptions of setting up relationships requires a PhD to understand the content being discussed. The word used to describe the relationships are uniquely Apples approach in terms. for example; reflective relationships is used to describe
(This entity can be the same as the entity at the source). Most database relationships use the term primary key, and foreign key. With the primary being the parent and the foreign key being the child relationship. In Apples description there is no reference to a parent or child relationship.
What I'm trying to do is to make it both easy for myself to understand and other people who may be using the form to better understand terms being used in the Xcode help. The following is a list of terms used in Xcode help that could be clarified. The bold and underline text is the text in question.
1. In the Type field of the Relationship pane, you can specify a relationship as being to-one or to-many, which is known as its cardinality.
2. What is the correct usage in Xcode: "Mutable"?
mu·ta·ble
liable to change."the mutable nature of fashion"synonyms:changeable, variable, varying, fluctuating, shifting, inconsistent,unpredictable, inconstant, fickle, uneven, unstable, protean;
literaryinconstant in one's affections."youth is said to be fickle and mutable"
3. How you model a many-to-many relationship depends on the semantics of your schema. This needs to be in plain English for example: create a many to many relationship where the parent and child links allow for duplicate entities. It would help to have an example of the schema being described as far core data requirements are concerned.
4. You can also put upper and lower limits on the number of objects at the destination of a to-many relationship. The lower limit does not have to be zero. You can specify that the number of employees in a department must be between 3 and 40. You also specify a relationship as either optional or not optional. If a relationship is not optional, then for it to be valid there must be an object or objects at the destination of the relationship.
Prior to starting a discussion on the upper and lower limits on the number of all objects, my question is why would you use upper and lower limits to start with? Why would it be important to have any kind of limits in the number of relationships within the link? This should be the first thing discussed as to why so that it would clarify whether or not to use upper and lower limits.
5. Cardinality and optionality are orthogonal properties of a relationship. You can specify that a relationship is optional, even if you have specified upper and/or lower bounds. This means that there do not have to be any objects at the destination, but if there are, then the number of objects must lie within the bounds specified.
This entire paragraph should require some degree of explanation prior to stating the usage of optionality? In number 4 a similar clarification was required to understand how and why to set the optionality.
This is an extremely important part of the description of relationships within core data, and it leaves me asking many questions.