Re: [newbie] one-to-one relationship both ways
Re: [newbie] one-to-one relationship both ways
- Subject: Re: [newbie] one-to-one relationship both ways
- From: Jeff LaMarche <email@hidden>
- Date: Thu, 25 Sep 2003 19:08:26 -0400
On Thursday, September 25, 2003, at 05:56 PM,
email@hidden wrote:
EOF really wants a to-one relationship to have a primary key as a
desintation attribute. As of WO5.2 (and maybe WO 5.0), EOModeler will
even warn you if you create a to-one relationship that is not to a PK.
Now, that doesn't neccesarily mean that it won't work if the to-one is
not to a pk. I've never tried it. I can't figure out how it WOULD, but
if
you've done it and it seems to then I believe you.
I've actually never had reason to do it where NEITHER side of the
relationship was a primary key - that would be an indication of a
design problem I would think, but IIRC (and I may not, it's been a long
day), you stated that both sides had to be joined on primary keys, and
I HAVE made relationships where one side of the relationship was not a
primary key. Now that I think about it, I think I may have not fully
understood what you were saying when I replied to you =/
But in my experience, when it's obvious that EOF would rather you
didn't
do something (and in this case, it is, especially because EOModeler
warns
you about it), you are really better off not doing it.
I agree, except that EOM is a developer's tool, and not a DBA's tool,
and I have seen situations where either platform limitations or
performance implications have forced me to changes things to a way that
EOF doesn't like. That's rare nowadays - databases have gotten
considerably better over the last few years.
There have been times when I've really needed to have a one-to-one
relationship though, usually for legacy reasons. What I've done there
is
to essentially put a foreign key in BOTH entities/tables. So it's
essentially two completely different relatioinships. A to-one from A to
B, and another to-one from B to A, joining on completely different
keys.
Both relationshops are to a PK.
This is the scenario I was envisioning... I think I misunderstood your
comment. Sorry 'bout that.
Another option, I've never tried: If the intent is just to keep
certain
data out of memory until you need it, you could try defining TWO
entities
both on the SAME table. But each includes a non-overlapping subset of
all
the potential columns/attributes and relationships that could be
defined.
Then you could have a to-one relationship from either one to the other
that did have a PK as the destination. Since a given row in the db will
really belong to TWO differnet entities. This would have it's
drawbacks.
Care would need to be taken to maintain a consistent object graph.
Deleting an object of one entity would really delete an object of the
other two, but EOF wouldn't realize that other one was gone. It would
get
tricky.
Sounds scary. And while memory footprint is one potential performance
problem with large columns, I was also thinking of performance issues
on the database side. If you have a table filled with long varchars and
blobs, it used to be that you could have problems, although it doesn't
seem to be the case with the databases I work with these days. Some
platforms also have (or used to have) limitations on the number of
blobs and/or long fields that could be on a single record, so I've seen
situations where applications had to "break the rules" of normalization
to make the database happy, or intentionally re-design their app to
work within those limitations. Again, my gray hairs are showing,
because these don't really happen much on modern RDBMS's, but once
bitten and all that...
You can also, of couse, simply have two different tables with rows that
use the SAME PKs. This could probably be accomplished with the
'propogate
primary key' attribute on a relationship, perhaps also with 'owns
destination', although 'owns destination' usually gives me nothing but
trouble, personally.
I avoid it as well. In fact, I find I design in EOModeler completely
differently than I do when I'm designing a data model by hand using
SQL, but some of that may just be that I've been using SQL longer and
am more set in my ways with it... (I still wish EOM let you order the
fields the way you wanted them, rather than alphabetically, without
having to rewrite the SQL...)..
So, bottom line, I think we're preaching from the same gospel, I just
wasn't being very careful when I read your e-mail...
Jeff
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.