db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <mse...@segel.com>
Subject Re: single file database?
Date Thu, 15 Dec 2005 03:55:24 GMT
On Wednesday 14 December 2005 6:39 pm, Roger Keays wrote:
> > If a developer uses Derby for storage this
> > would get cumbersome.  Zipping the derby DB
> > directory is one approach, but that
> > complicates application saves, crash recovery,
> > etc.
>
> That is what I had in mind. I read the Derby already offers read-only
> access to zipped files so thats already half way there right?
>
Uhm no.

> OOo uses a similar approach with its file format. The hsqldb jdbc driver
> is modified/extended to use an alternate IO stream which reads and
> writes to and from the compressed file. I don't have the source in front
> of me but from memory it works something like that.
>
> Roger

Think beyond "persistence of the object".

Its funny. J. Roy was just in town today. Kinda touched on this issue.

If you want, take a look at how postgress does their storage. The use of a 
Tablespace. A tablespace is tied to a chunk which is your "single file" 
storage unit. Only you don't just want to stop with a single chunk. (Cooked 
or Raw) Then you hit limits. What a 32-bit FS would limit you to 2GB per 
file? Also doesn't scale well. So if you have multiple table spaces you can 
grow fairly large.

Now if Derby did something like this, and cleaned up some troublesome bugs, 
then you'd have a *real* database that could easily compete with the front 
runners for about 70% of the DB Space. The other 30% would require a 
commercial grade product.

Note I don't suggest following how Postgress does something. just that their 
code is in the public domain and you can use it for an educational template.


Mime
View raw message