Re: Why no 1to1 relationships?
Re: Why no 1to1 relationships?
- Subject: Re: Why no 1to1 relationships?
- From: Jeff Schmitz <email@hidden>
- Date: Wed, 2 Apr 2008 17:18:35 -0500
On Apr 2, 2008, at 4:19 PM, Chuck Hill wrote:
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?
Just the performance, and being able to keep up with the rate of
transactions without having to buy more hardware. I guess I'm worried
about the speed of database transactions and all that checking being
very slow, maybe more than I should?
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?
Now don't hold back, tell us what you really think. :-) There's no
real problem other than improving throughput for a short period of
time. It's really how it's handled now, except using flat files and
not a database to save the data (basically each session updates its
own file), and it's not been a problem. Any specifics as to what's
"totally nuts" as long as the guarantee holds up? Or is it the
guarantee (no two existing sessions will ever update the same record)
itself that you question?
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