问题
I am working on an iphone app that uses core data. The data includes large list of people. Each person will have certain attribues which are the same. First Name, Last Name, age and few more. Then these people will be divided into categories. The problem that i am having people who are in different categories will have different attributes.
For example
Person A will be in category A and will have attributes a,b,c
Person B will be in category B and will have attribues b,c,d
Person C will be in category b and c and will have attributes c,d,e
I am thinking to have Entity Person
Entity Category
Entity personattributes which will store attributes for all the once that do not apply to this person will just be null.
In the code i will know if the person is category a he will only have attributes a,b,c
Will that be a good design or i would need a separate attributes entity for each category
Thanks in advance!
回答1:
In the absence of other design considerations, I'd use a single Person entity, with an attribute for the category, and attributes a, b, c, d, and e.
If you want to go a little further and require unsupported attributes be nil, I would look at attribute validation. Implement validateA:error: to return YES or NO based on the object's category, and so on.
回答2:
So each category has its own set of attributes? Might make sense to make a CategoryAttributeSet class, which could serve as the base for CategoryAttributeSetA, CategoryAttributeSetB, etc... First name, last name, and all of the properties common to all Persons could be instance data of the Person class, and then category-dependent attributes could be stored by having each Person maintain an array of type CategoryAttributeSet with attribute sets corresponding to each Category that the Person belongs to.
Just a suggestion.
来源：https://stackoverflow.com/questions/10637556/what-would-be-a-good-way-to-design-this-core-data-database