On Apr 6, 2008, at 1:13 PM, Daniel DeCovnick wrote:
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
I often model categories as many-to-many relationships. I think this
is a bit harder on the database but easier on humans. But I also take
this to some extremes. But people think naturally of categories in a
many-to-many way.
I would also encourage you to map out what might happen if, for
example, one needs to split a Problem into two or more Problems, to
let different people deal with different parts of the problem.
And you might have a situation where one person judges a problem to
be extreme and another wants it only to be moderate. "I can't think
of a case...". I also worry if I hear myself saying that. :-) Along
with "It should be easy if we just..." or "I am sure nobody would
notice if we...", etc, etc.
- ray
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
