Re: storing data in a desktop app
On Feb 27, 3:43 pm, Tom Anderson <t...@urchin.earth.li> wrote:
On Sun, 27 Feb 2011, David Segall wrote:
markspace <-@.> wrote:
On 2/26/2011 9:12 PM, harryos wrote:
Is it a good idea to use rdbms in a desktop app?
I wrote a similar app a while back for myself. I didn't use a RDBMS=
..
It seemed far too complicated for just a little time keeping app.
Instead, I just used POJO domain objects, and serialized the object
graph to disc. Simple and easy. Now if you have more sophisticat=
ed
needs than I did, maybe an RDBMS makes sense. But I'd try it with
POJOs first, it might work just fine.
Why write the code required to try it with POJOs?
Because it's about six lines - three to save, three to load. Working with
an RDBMS is pretty easy, working with an ORM is even easier, but working
with objects and serialization is dumfoundingly easy.
An RDBMS provides far more functionality
True - and where that's needed, and RDBMS is a great way to get it.
and consists of documented, extensively tested, code.
As does serialization.
That does not mean that serialization is easy to program.
It is not.
Even a little time keeping app probably requires referential integrity
to ensure that, for example, the project you say you are working on
exists.
Serialization provides that. Or rather, the Java object model provides
that, and serialization captures it.
I'm not saying that serialization is a good choice for all situations, bu=
t
it's an eminently reasonable thing to do for a simple app, or as a first
cut at storage in a complex app. Start with it, and add a database when
you have a reason to.
Given the relative ease of RDBMS programming and the trickiness most
people ignore in handling serialization, plus the propensity of any
successful software package to grow and expand, starting with a
cleanly-separated persistence layer and an RDBMS is not a very risky
choice.
Serialization will get your prototype out the door, but somewhere in
Week 2 you're going to start trying to report on the persistent
information using /ad hoc/ query dimensions.
Java serialization also locks your class design into yet another
public interface, only this one includes the private implementation.
That's a heavy maintenance price to pay for trying to make life
easier.
At the very least, read the warning, cautions and idioms in /Effective
Java/ regarding serialization before you shoot yourself in the foot
with it.
Given the low overhead of RDBMSes and the plethora of frameworks such
as JPA to work with them, and the dangers and difficulties of
serialization, I would never consider serialization as a persistence
mechanism.
--
Lew