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" <[EMAIL PROTECTED]> Date: Wed, 14 Dec 2005 08:51:03 To:Derby Discussion <[email protected]> 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
