storing data in a desktop app

[heyx]

how about xml? xml can served as database,it's easy to use.

 

[David Segall]

The link labeled "IBM DB2 Express-C" wouldn't come up.

That's odd. It works for me. -Anyone?

The link to SmallSQL takes you to a page that lists the "Advatages
[sic]" of the product and points out that "It does not has [sic] a
network interface". I suggest you not include them any more.

McKoi DB tells us, "Note that Mckoi SQL Database hasn't seen a new
release since 2004." You should drop them, too.

When I first wrote the page I received some entirely justified
criticism about the programs that were omitted. I decided to include
all the open source databases that claimed to be relational and would
run in the same JVM as your application. I'm grateful for your
comments and I can see why you would not choose some of them. However,
I'm reluctant to omit them because I don't think that I should
restrict visitors to my choice of database products.

 

[Lew]

When I first wrote the page I received some entirely justified
criticism about the programs that were omitted. I decided to include
all the open source databases that claimed to be relational and would
run in the same JVM as your application. I'm grateful for your
comments and I can see why you would not choose some of them. However,
I'm reluctant to omit them because I don't think that I should
restrict visitors to my choice of database products.

Without any added value, such as comments like, "Apparently not updated in
seven years, nor to Java 5 or beyond," a simple list such as yours is
essentially the same as what a search engine would yield, only less complete.

Among the top hits on the first page of
<http://www.google.com/search?q=Java+relational+database++"open+source">
are

<http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems>
and
<http://java-source.net/open-source/database-engines>

which have overlapping but different lists from each other's and from yours.
(Wikipedia's is not limited to open source.) You have not listed every
possible open-source RDBMS, based on what I see there.

Both of those lists are exemplary for their summary descriptions. You don't
need to visit every link to compare the systems, just the ones that make it
through triage.

As far as it goes your page is accurate and probably useful.

 

[Tom Anderson]

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

 

[Lew]

Could you expand on this widely-ignored trickiness?

The best explanation is the referenced chapter in /Effective Java/. Mr. Bloch
explains it far better than I can here.

But it boils down to what I already mentioned:

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.

It's always the case, just not a problem until you need to deserialize old
objects. Just like protected methods are part of the exposed interface, even
if you never create a subtype.

Knowing this, one can protect against it.

You can use serialization if you are sure about its consequences. The
consequences may be managed by your usage pattern, but you still need to know
about the boundaries.

The topic here is data storage. This opens to the door to scenarios where
classes change but persisted information does not. If the scenario of long
product life with data or relation changes over similarly long-lived persisted
data does not apply, or you contain the way that it does, you're still being
responsible for the limits of the approach.

I do not mean to say that one will always shoot oneself in the foot with
serialization, only that ignorance of its limits presents that risk. Really
it is not intended as a standin for a database system.

I completely agree with you that a DBMS is not a perfect fit for all programs,
and that Java's inbuilt serialization can be effective provided one is
responsible for the consequences and the limits.