Re: Are one-to-one relationships valid?
Re: Are one-to-one relationships valid?
- Subject: Re: Are one-to-one relationships valid?
- From: Daniel DeCovnick <email@hidden>
- Date: Sun, 6 Apr 2008 16:13:07 -0400
On Apr 6, 2008, at 3:36 PM, Ray Kiddy wrote:
On Apr 6, 2008, at 11:53 AM, Daniel DeCovnick wrote:
I've got a situation where I'm about 99% sure I should use a one-
to-one relationship. I've got about 100 attributes that can be
logically divided into 14 different categories. A single entity
(Note) would then have one of each of these categories (if modeled
as separate entities). There's no reuse possible of instances of
the categories.
Problem: The Create Relationship dialog in Entity Modeler won't
let me create a one-to-one relationship.
Question: Does this mean you can't have one-to-one relationships?
And if you can, how do you set one up?
Thanks,
Daniel
I think you are right. Entity Modeler does not seem to give you a
way to create this in the UI. One can create a relationship that is
to-one in one direction and then to-many in the other direction and
then one can edit the resulting relationships to make it to-one and
also to-one in the reverse direction. There seem to be a bunch of
warnings in the Problems tab as one does this, but it should work.
FYI, I find that the way a one-to-one relationship makes sense is
that the join needs to be based on the primary keys of the
entities. The old EOModeler would complain if one set up a one-to-
one in any other way. If you are not wanting to join the two
primary keys, you may not really want a one-to-one relationship. I
often find that I have given myself some flexibility if I create
the relationship as to-one in one direction and to-many in the
other and then, in the application logic, I can decide how to make
the to-many point to only one object. One can re-write the
accessors in the entity classes so that one can forget that this
really is not a true one-to-one. A real one-to-one implies quite a
lot about the structure of the schema. If you have real one-to-one
relationship, you might actually be wanting to use a table with
vertical entity inheritance. It is at least worth thinking through
the issues. If you are not so sure of the purity of your schema,
are you really sure you want a true one-to-one? There are lots of
situations where I want a one-to-one but then find reality to be
more messy than that.
One should respect one's primary keys and rely on them
appropriately but sparingly.
cheers - ray
I can't think of a case where I'd ever need the primary keys to be
different. The application, or at least this part of it, is basically
an electronic replacement for a paper form full of checkboxes and
notes fields, which are listed under headings on the form. Obviously
there's a FEW things that are reusable, such as a Person entity
(Note<<--->Person), and a FEW things that do have a legitimate to-
many relationship with Note, such as PhoneCall Entity (Note<---
>>PhoneCall), but I've already modeled them (BTW, the Migration
classes in Project Wonder kick ass!).
I suppose I could rework it, such that all the categories get full
one-to-many (Note<-->>[Category]) relationships, with the options
from the form as preexisting database entries, but I'm not sure
that's worth the trouble, especially since a lot of them are mutually
exclusive, for instance: the Problem Level category has as options
extreme, severe, moderate, mild, and none or minimal. Doesn't make a
whole not of sense to be able to have a more than one Problem Level
per Note.
-Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden