I have an application that manages two kinds of data: A singular file
that contains a large amount of rarely changed (but not invariant)
data, and documents that contain one root object's worth of
information that connects to the singular data set in a very large
number of places; the documents are in fact little more than a chosen
list of references into the singular data set, plus some small bits of
independant data. The documents are modified quite often.
Originally I thought Core Data must surely be ideal for this sort of
application; the object graph management alone should have been very
helpful, to say nothing of the management of stores and the abilty to
integrate with bindings and NSDocument. I got as far as reading all
the basic (and some of the not so basic) Core Data documentation and
began wondering whether or not my data would fit into its model after
all. For example, in the large singular data set, there are a large
number of what SQL would call "lookup tables", data that's used only
to avoid duplicating a set of constant values that are used elsewhere.
To use the Employee/Department example from the Core Data docs,
sometime in the future an Employee might have a "planetOfOrigin"
attribute. Assuming one limits one's self to the restriction of the
speed of light (so, not TOO far in the future), the resulting Planet
entity would only ever have a small number of possible values. Such an
attribute might be better modeled in the Employee entity by something
like SQL's ENUM or SET types. If the set of possible values is "Earth"
and "Not Earth", a Boolean might make more sense. If the set of
possible values is "Earth", "Mars", "Venus", etc., an ENUM would be a
reasonably obvious choice; after all, how often does the solar system
gain or lose a planet (cough Pluto cough)? With such a small data set,
a lookup table would only be the obvious choice if the set of possible
values was expected to change with any frequency. But Core Data has no
support for such a thing; I would either have to write a custom
property type or model it by creating the Planet entity and giving it
a relationship from Employee.
Let's pretend the lookup table *was* the obvious choice for some
reason; the speed of light barrier has been broken and now there's a
whole mess of planets. So in Core Data parlance, the Employee entity
has a one-to-one relationship to the Planet entity. The inverse
relationship from Planet to Employee, "all employees from this planet"
is technically feasible, even easy, to model, but it's almost
certainly a waste of time and effort. But the Core Data documentation
offers a long list of very dire warnings about one-way relationships
between entities.
Worse, the list of possible Planets certainly doesn't belong in the
same document file that holds a single Employee's data; you'd end up
duplicating that data across every single Employee. So the list of
Planets would instead be in a global store. But oops, Core Data can't
model cross-store relationships, so you use a fetched property, which
is one-way. Inverse relationship problem solved, unless you actually
had a use for that relationship. But fetched properties need a fetch
request, and what do you put in the predicate? Now you need some kind
of identifier in the Employee for the fetch to operate on, and now you
have two fields (the "planetOfOriginName" string for the predicate and
"planetOfOrigin" as the fetched property) to model a single
relationship. How to maintain referential integrity? And what if you
DID want the inverse relationship - do you model another fetched
property in the other direction? What's the predicate there,
"planetOfOriginName LIKE [c] $FETCH_SOURCE.name"? Now your Planet
entity has intimate knowledge of the structure of your Employee
entity; that can't be good.
It seems to me that Core Data really is intended to deal with lists of
root objects, i.e. the entire list of Employees in one store, rather
than one Employee per store. The Core Data documentation mentions
attaching multiple stores to a persistent store coordinator, but I
can't make any sense of how interrelationships between the stores are
handled.
Is Core Data really more appropriate to my dataset than an SQLite
database and a simple Employee object that fetches from that database?
If so, I'd appreciate some help in understanding how.
(Let me take this opportunity to say that for all the warnings that
Core Data is not and never has been a database, almost every concept I
see in it makes me think "O/R mapper for SQLite".)
-- Gwynne
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
