HI Jeff,
On Apr 2, 2008, at 3:18 PM, Jeff Schmitz wrote:
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?
That would be my guess. Lets say you have the PK and 12 fields
selected for locking. The PK will uniquely and very quickly identify
the single row to update. That means for each UPDATE the database
will be doing an extra 12 == operations to verify the WHERE clause.
If that is going to kill you app, it is pretty much dead already.
Fetching is what is going to cause problems, not locking.
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. :-)
:-P
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
OK, now _that_ is really whacked out!
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?
Either you need the locking to prevent update problems, or you don't.
If you don't need it, don't use it at all. If you do need it, turning
it off just "turns on" update problems. And that is nuts!
Chuck
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 (Webobjects-dev@lists.apple.com)
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
This email sent to [EMAIL PROTECTED]
--
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
--
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 (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]
