Re: Why no 1to1 relationships?
Re: Why no 1to1 relationships?
- Subject: Re: Why no 1to1 relationships?
- From: Chuck Hill <email@hidden>
- Date: Wed, 2 Apr 2008 14:19:59 -0700
On Apr 2, 2008, at 1:09 PM, netBrackets wrote:
Thanks for the great comments. And 1:1, owned/mandatory data etc.
is what I want.
I perhaps have an unusual case in that for a small minority of days
I experience bursts very heavy activity, with changes occurring on
only a small subset of my data during this period
And exactly what problem does this result in?
and furthermore, changes to any one record can be guaranteed
(through disabling a few features of the site temporarily) to be
made by only a single session. I have an idea that I'd like to
segregate this changing data into its own table, and then on the
"heavy days", turning off all locking on the table (along with
disabling the required site features to assure single session
changes) to speed things up. Which leads to my next question, might
there be a way to easily disable lock checking on a single table,
and then turn it back on without having to create a whole new build
and or re-create my database schema?
I think it would be fair to characterize that method of handling this
situation as "insane", "crazy", "wacked out", and "totally nuts".
Unless your goal is data inconsistency. Maybe we should look at the
real problem?
Chuck
On Wednesday, April 02, 2008, at 02:12PM, "Art Isbell" <email@hidden
> wrote:
On Apr 2, 2008, at 8:45 AM, Robert Walker wrote:
Yes, it is possible to create one-to-one relationships, joined on
the primary keys. One side of the relationship will need "Propagates
primary key," as has been mentioned.
I just wanted to add one caveat to this configuration: The
relationship will always be 1-to-1 and will never be 1-to-0. In
other words if you created an instance of the entity on the side
propagating the key, you will get an instance of the other side of
the relationship. This will happen even if no fields are set on the
other side. This means that if any attributes (other than the PK) on
the other side of the relationship are set to required, neither
object will save.
Also if you attempt to create a new instance on other other side
(not propagating the key) you will also have problems saving.
As far as I recall this is the experience that I've had when
attempting to do this. Because of these complications I now opt for
the more flexible one-to-one style by setting it up in the model as
a one-to-many relationship. Then force the many-side to allow only
one or zero related rows though validation logic.
Another way of stating this is that a one-to-one relationship must
be
mandatory (i.e., it cannot be optional). This makes sense because
the
foreign key in a one-to-one relationship is the primary key which
cannot be null and is guaranteed to be unique. If a foreign key is
not null, the destination object must exist. If a foreign key is not
the primary key, it is not guaranteed to be unique, so an attribute
that is not the primary key cannot be the foreign key of a one-to-one
relationship.
I think that this agrees with relational database theory; i.e., all
one-to-one relationships must be 1:1, not 1:0. A 1:0 relationship is
just a special case of a 1:many relationship.
Aloha,
Art
_______________________________________________
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
_______________________________________________
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
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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