Re: CoreData modeling a mutable attribute set for an entity
Re: CoreData modeling a mutable attribute set for an entity
- Subject: Re: CoreData modeling a mutable attribute set for an entity
- From: Jesse Grosjean <email@hidden>
- Date: Tue, 3 Jan 2006 16:06:18 -0500
Jeff and Matthew,
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
ExtendedAttributeClass
name (string)
stringValue
ExtendedAttributeClass
name (string)
integer16Value
integer32Value
integer64Value
decimalValue
doubleValue
floatValue
stringValue
booleanValue
dateValue
dataValue
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:
This email sent to email@hidden