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 17:22:37 -0400
On Apr 6, 2008, at 4:45 PM, Ray Kiddy wrote:
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
Maybe I'm not explaining what I mean by a category very well, but I
don't see how the categories naturally model as many-to-many.
I see what you're saying on the second and third parts. I guess I'm
not thinking far enough forward. Right now, what you describe really
is impossible; this version is for a single private-practice doctor's
use. I'm doing it in WO/EOF instead of Cocoa/Core Data for portable
access and offsite storage reasons (of course I only got those
requirements once I'd modeled it in Core Data), but yeah, I could see
a case where a multi-person office would want this, and and want
different folks opining on a 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