Re: Issues with unique object IDs in persistence
Lew wrote:
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.
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.
(Consider how much trouble typical computer users have if a problem
requires fiddling with the Windows registry; that's probably a good
indication of how they'd cope with any DB issue without a simple
No registry fiddling required. Red herring. Derby is started by the
application within the same JVM. No DB administration required. No
pressure on the user at all. All the responsibility is on the
programmer.
push-button fix. Most likely they'd have to uninstall and reinstall to
recover, realistically. If the application is targeted at users with a
higher level of computer science education/technical skill than the lay
public, then it might not be a problem. If the application is targeted
at server admins, dealing with databases is already part of their job
description.)
Why don't you read up on Derby and rethink your arguments?
To be clear, I'm not knocking using a full-blown database. I'm noting
that there will be situations where it's the best solution, and there
will be situations where it isn't.
I think it likely that Derby or another embedded database (though
Derby is the one that already comes with Java) will be simpler than
the disk-based solution recommended upthread, by a wide margin, though
not necessarily simpler than a Map-based solution.
--
Lew