Re: Collections can be simple Attributes in Core Data
Re: Collections can be simple Attributes in Core Data
- Subject: Re: Collections can be simple Attributes in Core Data
- From: Negm-Awad Amin <email@hidden>
- Date: Tue, 7 Oct 2008 09:14:15 +0200
Am Di,30.09.2008 um 19:58 schrieb I. Savant:
On Mon, Sep 29, 2008 at 3:03 AM, Negm-Awad Amin <email@hidden
> wrote:
But now I find there is an even more natural way, which is to just
leave
them as a set or array, and store in an attribute of type
Transformable.
The default transformer en/decodes the collection into/from an
NSData, and
everything "just works".
I'm surprised that I've never seen this discussed or documented.
Is this
going to get me into any trouble?
Yes, because you get redundant and inconsistent model.
If I'm reading this right, Jerry has a simple attribute called "pet
names". Usually this is used as a personally-identifiable unit of
information. Sure, lots of people might have fluffy, but do you really
need to have a "PetName" entity, checking to see if an instance with
"name" property equal to "Fluffy" exists, creating one if not? In this
case (where we just want to store a short list of very personal things
as an attribute), sure you can archive an array or a set, just like
any other archiveable object.
Now if the application needs to track people and their pets, I'd
imagine you'd have a whole "Pet" entity with a "name" property, but
that doesn't sound like what Jerry is getting at ...
When I read this:
"[…]Person's pets,[…]"
I assumed, that he has a person entity. Pets are persons, too. So I
wouldn't create a new pet entity, but using a reflexiv relation to
person to model the pets.
However, if it i a simple list of names related to nothing, you can
model this with an simple array (or set) without creating an entity
and relationship. But anyway, this is dangerous, too: Let's have a
person (an instance of a person entity)
"Amin Negm" with the pets "Dieter Müller", "Peter Schmitz" and
"Michaela Schneider"
and a person
"Jerry Krinock" with the pets "Jo Miller", "Peter Smith" and (the
same) "Michaela Schneider".
Now imagine, that Michaela marries and her name changes to "Michaela
Suhrbier" …
The basic problem is, that a pet's name references something (an
"entity" in its original philosophical meaning) outside the model. And
the "silent assumption", that one attribute refers something outside
the model, can fail: The name of a person can change without changing
the person. (Okay, when Michaele marries, maybe she changes her
personality. But this has nothing to do with IT, ;-))
In contrast to this, sometimes there is no problem doing so: If there
would be colour attribute, say the colour of the hair, it is correct
to model simply a string like "brunette" and so on. Even if Michaela
changes the colour of her hair, this would be a change of *her* hair.
We would have the problem mentioned above only, if the name of the
colour would change, say that "black" is called "zusgaasee" in future,
This won't happen … *pray*
The 'correct' approach depends entirely on the model.
Of course …
--
I.S.
Cheers,
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden