Re: Issues with unique object IDs in persistence

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 17 May 2009 20:12:04 -0400

Message-ID:

<4a10a7d1$0$90270$14726298@news.sunsite.dk>

Seamus MacRae wrote:

Lew wrote:

Seamus MacRae wrote:

Heavyweight also involves such factors as code and data size,
configuration headache-inducingness, and complications to deployment.
For example, if the project is a desktop application, can you ask your
users to install a database server? Can they be expected to know how to
fix it if something gets corrupted that persists across reboots?

You don't have to ask the user to install an embedded database; that's
what "embedded" means. You install Derby with the application.

That has its own problems, namely, the user using several such
applications ends up with several copies of the DBMS chewing up disk
space (not just several databases, which was not avoidable, but several
database SERVERS too).

It is a 500 KB jar file. You can have 10 or a 100 of these without
noticing it.

The database will in effect have no user-serviceable parts inside. If
anything gets wacko in it, the typical user's only realistic recourse
will be the uninstall and reinstall the affected application. And then
they lose whatever the database is used to store.

Derby is started by the application within the same JVM. No DB
administration required.

Until something goes wrong.

That is approx. the same for all binary formats.

Arne