Configuring Core Data Entity to Store NSArrays / NSSets, etc

Question

I want to store a number of objects into Core Data which contain collections in addition to other scalar variables.

For example, I may want to persist several thousand "Machine" objects:

@interface Machine : NSObject <NSCopying>
{
    NSString *idNumber;
    BOOL existsInLibrary;
    NSSet *sections; // Contains a set of NSStrings
    NSSet *banks; // " "
    NSSet *positions; // " "
    NSMutableArray *orientationIDs; // Contains an array of NSNumbers
    NSMutableSet *credits; // Contains a set of NSNumbers
}

There are numerous similar SO questions, but there does not seem to be a singularly definitive consensus on how to accomplish this. Do I want to serialize the collections into Binary Data attributes? Or should I utilize the "transformable" type? Or do I want to make several one-to-many relationships?

From what I've read, the latter of these solutions is the most appealing to me, although I am not sure if it makes the most sense in my situation, where the collections merely contain NSNumbers/NSStrings as opposed to other custom objects (which nearly every solution using this method seems to take for granted).

If you could enlighten me by explaining when each of the above tactics is situationally the most effective as well as with which you think I should apply to my own scenario, I would be very grateful!

Furthermore, should the answer be "use a one-to-many relationship" - does this mean that I need to make a distinct entity for each and every collection-type variable? Ultimately this would result in several dozen entities with one-to-many relationships if I were to apply this to all of the objects that I need to persist; is that to be expected, or am I thinking about this the wrong way?

Thanks!!

Answer 1

Serializing to a binary data attribute and using a transformable attribute are really the same thing, implemented in somewhat different ways. Both involve converting your collections to/from NSData.

Which approach you should use depends on how you expect to use the data. Serializing the collections will be simpler, but it has the limitation that you can't search for objects by serialized values. If you need to look up objects by array values (e.g. find Machine instances that have specific values for sections or banks in their collections), serializing to binary is not a good approach. On the other hand if that never happens, it wins just by being simpler to write and maintain.

If you use a to-many relationship for any of these attributes, you would need to create a new entity type for the values. This could be a distinct entity type for each attribute. Or, if they all contain the same type of data, you could use a single generic entity type, called something like MachineRelatedItem. You'd have multiple to-many relationships to that entity type.