Re: Globally unique IDs
Re: Globally unique IDs
- Subject: Re: Globally unique IDs
- From: Ben Trumbull <email@hidden>
- Date: Sat, 7 Feb 2004 14:46:05 -0800
At 13:45 -0500 2/6/04, Colin O'Brien wrote:
It seems the automatic private key mechanism in WO only provides unique keys
within a single database.
Yes and no. EOF can only support an Entity mapping to a single
database at a time. So the Table+rowPK is unique within a scope
beyond a single database (all apps using that Entity's model;
glossing over entity inheritance).
It's not uncommon practice to manipulate the models, connection
dictionaries, model groups, and EOF stacks
(EOObjectStoreCoordinators) at runtime. So, indeed, it's not
difficult to create a situation where the PKs are no longer unique
with multiple databases even within one app.
The questions then would be
* is there going to be a noticeable performance hit using VMID's (40 bytes)
compared to the more typical int?
more concerned about retrieval performance than update performance
It will definitely be a performance hit. A single integer PK is far
and away the most performing in both speed and memory. And for
selects and joins, making the db compare 24 bytes instead of 4 is
obviously more work per row. More data to push back and forth
between app & db, etc.
As for "noticeable", you'll have to benchmark your application to
decide whether or not you care. I would be very surprised if this
became your bottleneck.
On the flip side, if your queries are already sufficiently complex
and pushing the boundaries of responsiveness, this could be the last
straw.
Maybe someone else on this list has performance numbers for different pk types.
* would it be better to use the built-in PK system and have a separate column
for the VMID?
I would encourage you to explore this option first. If this is
tenable for your transitions between databases, it's better. But if
the VMID works better from a development point of view, the db time
is worth a lot less than yours.
--
-Ben
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.