Re: storing data in a desktop app
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--232016332-1154766608-1299016782=:10309
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Mon, 28 Feb 2011, Lew wrote:
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.
Why write the code required to try it with POJOs?
I'm not saying that serialization is a good choice for all situations,
but 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
Could you expand on this widely-ignored trickiness?
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.
Cleanly separated persistence layer, yes, absolutely. RDBMS, when you need
it.
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.
We're in year 2 of our current project, and i don't think we have any
reporting at all. In our case, that's because all the stuff people might
want to report on goes into other systems, which already have means for
reporting. Our objects live in an RDBMS, and there are lots of them we do
query, but a large swathe of them could be stored with serialization with
no loss of functionality.
Java serialization also locks your class design into yet another public
interface, only this one includes the private implementation.
You mean because you need to be able to open old files? That's only the
case if you need to be able to open old files.
At the very least, read the warning, cautions and idioms in /Effective
Java/ regarding serialization before you shoot yourself in the foot with
it.
I can't argue with that.
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.
And i wouldn't presume to argue with that!
tom
--
I think the Vengaboys compliment his dark visions splendidly well. -- Mark
Watson, on 'Do you listen to particular music when reading lovecraft?'
--232016332-1154766608-1299016782=:10309--