问题
I'm trying to work for a long time with the core data.
And I read a lot of tutorials about this and i asked a lot of questions.
Finally I started to work on core data
Through this guide: www.appcoda.com/introduction-to-core-data/
And now I'm stuck!
I want to create the kind of attribute, array.
And was told me it's a not a good way to store array about attribute.
These work with a relationship.
But the problem here.
If you look at the guide, it does not create files (classes) entities
And all the other guides. Yes creating files, so they do not help me so much because I do not have my entity files.
Is there a way to create the kind of relationship that behaves like array to one attribute, without me having to make file creating entities?
Because of my project is already very big.
回答1:
The reason people don't recommend using arrays as attributes for CoreData entities is this: the array has to be converted to raw data to store it to the persistentStore, and then has to be converted back when the object is read from the store. This has the potential to be slow, and the raw data could become "big". Importantly, because the attribute is stored as raw data, you cannot fetch a subset of the stored objects using a predicate that depends on the contents of the array attribute. So for example, you cannot (easily) fetch "only objects for which the array has only 1 member".
So, people recommend using a relationship. I would strongly recommend that you do create subclasses; it will make your life so much easier if you do. But it is possible to use relationships without subclassing. Suppose you have a Person entity (with name and dateOfBirth attributes) and a Course entity (with just a name attribute).
Assume each Person can attend only one Course, but each Course can attended by several people. You would create a to-many relationship from Course to Person, and name it something like attendees. The inverse relationship would be to-one named something like course. The model would thus look like this:
You are familiar with accessing attribute values using valueForKey and setValue:forKey:, eg. for a string attribute:
// Get...
NSString *myPersonName = [myPerson valueForKey:@"name"];
// Set...
[myPerson setValue:@"John Doe" forKey:@"name"];
Use the same methods to get/set relationships. For a to-one relationship, the value you get/set will be an NSManagedObject:
// Get...
NSManagedObject *personCourse = [myPerson valueForKey:@"course"];
// Set...
[myPerson setValue:myCourse forKey:@"course"];
For to-many relationships, things get slightly more complicated. Because a Course can have many attendees, the value you get/set is an NSSet:
// Get...
NSSet *myCourseAttendees = [myCourse valueForKey:@"attendees"];
for (NSManagedObject *person in myCourseAttendees) {
NSLog(@"Attendee's name is %@", [person valueForKey:@"name"];
}
// Set...
NSSet *newAttendees = [NSSet setWithObjects:newPerson1, newPerson2, nil];
[myCourse setValue:newAttendees forKey:@"attendees"];
That's all well and good, but sometimes you just want to add/remove one attendee:
NSMutableSet *attendees = [myCourse mutableSetValueForKey:@"attendees"];
[attendees removeObject:myPerson];
[attendees addObject:myNewPerson];
So, managing to-one relationships is far easier than to-many. Here's the good news: if your relationship has an inverse, whenever you modify it, CoreData will automatically update the inverse relationship for you. So if you have a to-many relationship with a to-one inverse, just use the to-one. Put another way, it's easier to use:
[myPerson setValue:newCourse forKey:@"course"];
than:
NSMutableSet *attendees = [newCourse mutableSetValueForKey:@"attendees"];
[attendees addObject:myPerson];
Both achieve the same thing.
Now, as others have pointed out elsewhere, you might in fact want a Person to be able to attend many different Courses. In that case, both the relationship and its inverse will be to-many, and you're stuck using the mutable set methods.
来源：https://stackoverflow.com/questions/34132781/core-data-in-storage-array-attribute-or-work-with-files-or-relationship-entities