Re: Issues with unique object IDs in persistence
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?
Lew wrote:
You don't have to ask the user to install an embedded database; that's
what "embedded" means. You install Derby with the application.
Seamus MacRae wrote:
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).
The data stored is the largest part of the disk overhead, which would be true
for the other disk-based solution, too, of course. Derby itself only adds 2
MB to the footprint - not much at all.
(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
Lew wrote:
No registry fiddling required. Red herring.
Seamus MacRae wrote:
I was using the Windows registry as an analogy. Fixing a problem in the
application's database and fixing a Windows registry problem would
probably be equally hard. The registry is probably easier: at least
Windows comes with regedit, which is a GUI app, and the Windows registry
is so ubiquitous lots of web sites provide technical information about
I would not tell a user to use regedit.
monkeying with it. The application's database will probably not be
widely documented online, not have a regedit-like GUI to directly fiddle
with it, and won't even be easy for the user to locate on disk. Once the
user found it, to manually fix it would require feeding the database
server some SQL queries. How many Windows users do you know who you'd
credit with being able to use SQL queries?
The users should not be doing SQL queries on an embedded application. Another
red herring.
Also, the comparison is between Derby, a simple database solution, and a
custom-written disk-based solution that has to deal with many of the same
troubles that Derby has already handled for you. In this comparison, I'd lay
odds that Derby wins.
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.
Same for the disk-based solution.
It may have its uses, but it's probably overkill for just storing window
positions and other state like that, and for anything it's not overkill
for, using it means users can easily lose years of work if something
goes wrong.
Same for the disk-based solution. Only the disk-based solution has more risk
of trouble.
System administrators can be expected to be able to recover from such a
thing, however.
System administrators are not the target market here.
Ultimately, it depends on what level of technical skill your application
is targeted at. Typical Windows users: uh-oh. Developers (say it's a
compiler or IDE): maybe OK. Sysadmins running network servers and the
like: should be fine.
I'm saying "typical users".
Lew said:
Derby is started by the application within the same JVM. No DB
administration required.
Seamus MacRae wrote:
Until something goes wrong.
And this is superior to the custom disk-based solution how?
the problem is that a custom solution carries much risk. Bugs happen. A
tested, mature product with a small footprint that has already weathered those
storms reduces the risk.
Seamus MacRae wrote:
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.
Lew wrote:
I think it likely that Derby or another embedded database (though
Derby is the one that already comes with Java) will be simpler than
Seamus MacRae wrote:
Implementation simplicity isn't the issue above.
I am saying that it is, along with maintenance simplicity and reduced risks of
bugs.
All the concerns you mentioned are valid, it's just that Derby represents a
lower risk with respect to those problems than the custom disk-based solution.
Plus, the programmer has a clean, well-documented model for data storage and
correlation with the Derby approach, and doesn't risk getting entangled in the
low-level details that a custom file-based solution would entail.
Calling Derby "full-blown" or "heavyweight" is misleading. It's actually
lighter weight and lower risk than trying to manage files oneself and still
get the functionality needed for the application. System administrators do
not get involved - everything is handled by the application. SQL queries are
not an issue for the users - everything is handled by the application.
Registry editing (yecch) is not an issue - everything is handled by the
application. The programmer's life is easier because Derby gives the
necessary functionality. Compared to low-level file manipulation that the
programmer has to re-invent, Derby is a lighter, safer, more powerful solution.
--
Lew