On May 17, 2005, at 4:41 PM, Bill Bumgarner wrote:
I don't think they are related. Or, more specifically, I don't
think they should be related.
Your application is confusing the data with the model. This is, in
my experience, a mistake in architecture (and a very common one).
If the data model changes over time, that model is, in and of itself,
also data and it should be modeled as such.
That is, you need a model that encompasses the fact that the user or
application may change the "model" of the data over time.
Whoa! I think you blew my mind!
<snip>
Rethinking the above problem, a simple approach would be to create a
"NameValuePair" entity that contains a name and a value. Your "item"
entity would then have a one to many to NameValuePair instances.
This would solve the problem in that the user can add any number of
new attributes within any name/value values that they might care for.
Now, obviously, it might be desirable to be able to ask questions
like "Give me all items that have a 'width' attribute attached to
them (maybe with a specific width)?". That could certainly be
expressed with a predicate. It could also be expressed in the
model. You could create an 'AttributeName' entity and then have
'NameValuePair' have a to-one relationship to the 'AttributeName'
entity (with a to-many inverse). You could also do something
similar for the values, thus creating, effectively, a pick list type
of attribute.
I wish I could visualize this!
1) Census data 1990
2) Census data 2000
And I want to be able to add any type of data at a later point (as data becomes available) that also references that same point on a map, but each will conform to KVC such as, for example,
Key: budget1990 Value: $10,000,000.00
Key: budget1991 Value: $11,000,000.00
.
.
.
Key: budget2000 Value: $20,000,000.00
But also later want to add other information that might become available but was unforeseen when developing the application:
Key: homelandSecurityBudget2003 Value:$1,000,000
.
.
.
I can model this by having a Graphic entity with a to-many relationship to an Attribute entity which has the properties attributeName and attributeValue. Then I just import the .dbf files as they become available assigning the column name to attributeName and the column value to attributeValue? But what about cases where the value can be a NSNumber or a NSString or a NSDate? It is simple using an NSDictionary. I haven't figured out how to do this with CoreData.
It would help me (perhaps it exists and I just haven't found it yet) to see a CoreData example that develops what amounts to an NSDictionary that stores any type of attribute, whether a number, string, or date and each NSDictionary is joined to a "master" entity (in my case a graphic).
Philip