=?iso-8859-1?Q? J=FCrgen=20Saar ?= <jsaa..eb.de> wrote:
> If you want the database to generate the primary key
> this is not really a good idea, because you might lose
> the the free choice of the databaseysystem you want to use.
> This is one of the key features of a framework like cayenne.
> For my point of view, it might have a little less performance
> but I like this kind of independence.
I'm no expert, but I suspect you have equivalent performance. WebObjects
uses the same kind of cross-database-platform methodology for generating
primary keys.
In every case, to generate a single insert, you have to have at least two
trips to the database.
Either you prefetch the new primary key then insert, or you insert then
postfetch the primary key.
For more than one insert, you can cache several primary key values in your
prefetch. This is true whether you use Oracle sequences or use the cayenne
database-table-based primary key generation.
The only thing that using a built-in database primary key generator gets you
is the ability to use non-cayenne frameworks to generate new records on the
same cayenne tables. And unless I misunderstand how it works,
post-fetching (because there's no ability to cache future to-be-used primary
key values) is going to be less performant than using the cayenne
methodology.
That said, sometimes built-in database key generation is less performant,
but still desirable. For instance, if you use OpenBase's built-in pk
generation, you can't cache future primary keys. However, it does guarantee
that primary keys returned will be unique across database clusters, which is
probably more important if you have clustered database servers :)
In any case, as folks continue to contribute new proprietary primary key
support for various databases, you can choose whether to use the default
cayenne key generation or the proprietary key generation.
-Mike
This archive was generated by hypermail 2.0.0 : Tue Aug 03 2004 - 11:57:31 EDT