Thanks. Looks like getting rid of my attribute type hierarchy is the
place to start. All those extra entities were making my CoreData
entity diagram to busy anyway!
Another option to consider is to use a single entity with a small
collection of specifically-typed attributes that can represent the
available options. For example:
ExtendedAttributeClass
name (string)
type (int)
stringValue (string)
numberValue (int/float/double/whatever)
dateValue (date)
dataValue (binary)
I'm think about going with this approach. Less work is always nice
and the overhead for empty attributes doesn't appear to be very
dramatic. So my last question of the day is what attributes to
declare in this ExtendedAttributeClass. The SQL storage difference
between these two possibilities for the ExtendedAttributeClass
only appears to be about 20% (extra space required to store empty
attributes). I don't mind using that amount of extra space, but are
their any other problems that might arise from having so many
attributes, even if they are mostly all empty?
Jesse
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
