2

From reading the Apple Docs on Core Data, I've learned that you should not use Core Data when you need a dynamic schema. If I wanted to provide the user the ability to create their own properties, in a core data model would it work if I created some "dummy" attributes like "custom decimal 1", "custom decimal 2", "custom text 1", "custom text 2" etc that the user could name and use for their own purposes?

Obviously this won't work for relationships, but for simple properties it seems like a reasonable workaround. Will creating a bunch of dummy attributes on my entities that go unused by most users noticeably decrease performance for them? Have any of you tried something like this? Thanks!

Gouldsc
  • 451
  • 3
  • 10
  • Can you try to explain how you envision these dummy attributes being used in practice? – Matthew Flaschen Mar 16 '10 at 03:40
  • Sure, so let's say you have a car entity in your model, and you might have some properties like color, make, model, year. But you might create some dummy attributes so the user could rename your "custom whole number 1" attribute to be used for weight, because that particular dealership using your app might need to track weight for calculating shipping costs or something that I can't anticipate. Another user of the software may use "custom whole number 1" for their inventory control number or something else like that. – Gouldsc Mar 16 '10 at 03:50

3 Answers3

2

First, see the Core Data docs on relationships. Using your example, consider something like:

  1. A CarAttributeType entity, with a name such as "weight in pounds"
  2. A CarAttribute entity with a value such as 2765.
  3. A Car entity, with the required values you mentioned (such as "color", "make", etc.)

Then, have a many-to-one relationship between CarAttribute and CarAttributeType (many CarAttributes can have the same type), a one-to-many relationship between Car and CarAttribute (each car can have many attributes). This solution is a bit more complicated to setup than the hard-coded NULL fields. However, it avoids repeating groups and is hopefully more maintainable.

EDIT: Yes, I missed that. I think you would want a StringCarAttribute, StringCarAttributeType, FloatCarAttribute, FloatCarAttributeType, etc. Then, have a many-to-one between StringCarAttribute and StringCarAttributeType, etc. Car will have one-to-manys with both StringCarAttribute and FloatCarAttribute. The reason for multiple type entities is so you don't have a StringCarAttribute and FloatCarAttribute, both declaring themselves to be using a single weight attribute type.

Having one CarAttribute with all the types goes against 1NF #4.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • How do I type the CarAttributes? I would need a StringCarAttribute entity and a FloatCarAttribute entity? or should I just create a CarAttribute entity with a floatValue, boolValue, stringValue, etc. set of attributes and then have the user choose the appropriate type and only use that value while leaving the rest as NULL? Your solution would allow an infinite number of attributes which seems more appropriate. I guess I hadn't considered using relationships in the generic sense. Thanks. – Gouldsc Mar 16 '10 at 04:59
1

One option is KSExtensibleManagedObject. Shove the dynamic schema bit in the extensible properties.

Mike Abdullah
  • 14,933
  • 2
  • 50
  • 75
0

It would work, it would just be awful. Think using a flat table in a database, because thats exactly what you'd be doing. Instead try creating a schema that can describe a schema in a way that your application can understand. There would still be considerable code involved however, although if done correctly you could mimic as much as a SQL database. Of course, core data is built on top of SQL (or other storage types but thats not my point), but basically you'd be creating a layer to mimic something two layers down which would just be silly.

Jared Pochtar
  • 4,925
  • 2
  • 29
  • 39
  • Thanks for the response. I'm mostly concerned with accommodating the unique usages that my users might have. I'm intending on building in as many standard/common properties that a user might need, but I also wanted to allow for the user to add in a few extra attributes of their own (since it's impossible for me to include/anticipate every use case they might have). – Gouldsc Mar 16 '10 at 03:39