db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Keays <roger.ke...@ninthavenue.com.au>
Subject Re: single file database?
Date Fri, 16 Dec 2005 08:16:59 GMT
Michael Segel wrote:
> 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,
>>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.
> 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.

Ninth Avenue Software
p: +61 7 3870 8494 (UTC +10)
f: +61 7 3870 8491
w: http://www.ninthavenue.com.au
e: info@ninthavenue.com.au

View raw message