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 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? Thanks, Jeff On Wednesday, April 02, 2008, at 02:12PM, "Art Isbell" <[EMAIL PROTECTED]> 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 protected]) >Help/Unsubscribe/Update your Subscription: >http://lists.apple.com/mailman/options/webobjects-dev/jeffandmonica%40mac.com > >This email sent to [EMAIL PROTECTED] > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
