db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Segel" <mse...@mycingular.blackberry.net>
Subject Re: single file database?
Date Wed, 14 Dec 2005 16:34:16 GMT
Perhaps I was not clear.

A "single" file for the database has limitations in size. For example some file systems have
a 2 GB limit..

The concept is to create tables spaces where each table space is a single file.
However you can have multiple tables spaces.  Now these files can either be cooked or raw.

So yes. You are correct that this should be the direction.  But there is a catch.  Who is
going to do this?
Are they really qualified to do this?  How do you resolve issues when the change in structure
effects other efforts?
How do you workout design philospohiesthat will effect the future of the product?

This is no small task.
-----Original Message-----
From: "Kervin L. Pierre" <kervin@adevsoft.com>
Date: Wed, 14 Dec 2005 08:51:03 
To:Derby Discussion <derby-user@db.apache.org>
Subject: Re: single file database?

Michael Segel wrote:
> On Wednesday 14 December 2005 2:42 am, Roger Keays wrote:
>>I saw on the derby todo list[0] that there were plans to store a derby

[...]

> That would be highly inefficient and wouldn't scale.
> 

Why SQLite does this ( http://sqlite.org/ )
and is very fast.  May be faster than Derby.

Application users are used to having a single
file manage a 'set of work'.  Eg. a PSD file
for work with an image, or a XLS, or DOC file
etc.

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.

Regards,
Kervin


Sent via BlackBerry.

-Mike Segel
Principal
MSCC
312 952 8175
Mime
View raw message