Re: Issues with unique object IDs in persistence
Lew wrote:
Seems like Derby (a.k.a., Java DB) or Postgres (among others) will
serve the need for a disk-based persistence mechanism with the ability
to maintain simultaneously a 'long' surrogate key and a unique
combination of values as a natural key. They have added advantages,
such as having already optimized access for single- or multi-user use,
having worked out the various algorithms such as unique ID generation
that one might need, coming with Java already in the case of Derby or
freely available in the case of Postgres and others, ready integration
with Java, scalability, and a host of other advantages.
Seamus MacRae wrote:
If heavyweight persistence is needed, or the application has other needs
that can be met by a database, a heavyweight database might be a good
back-end for the implementation, yes.
Derby hardly qualifies as "heavyweight" - learning enough to use it is
probably about as much effort as figuring out all the wrinkles of the
disk-based solution you outlined upthread. For that effort, you get a
well-thought out and heavily-tested solution and a skill set that increases
your marketability.
It might still be useful for the OP to have some clue how to implement
something like this on his own, for instance, for general advancement of
computer science skills, for specific application when a heavyweight DB
would be overkill, or for specific application when no existing DB
implementation quite fits a particular project's needs for whatever reason.
Of course, implementing one's own full-blown heavyweight DB is rather
more involved than just persistence. You need transactions and
atomicity, some kind of consistency checking, and probably some
structured records capability beyond just "ID number, hash, and
serialized Java Object". And you need a query engine, joins, and the like.
All of which come with Derby, Postgres and the rest. Derby is embeddable with
only about a 2MB memory footprint. It comes with (Sun) Java already. It's
very straightforward to use. So it has more power than you think you need at
first - the effort to use it is so small that all that extra power and
flexibility is not a disadvantage.
--
Lew