Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45954742.1010204@decoursey.net>
Date: Fri, 29 Dec 2006 10:50:10 -0600
From: Paul J DeCoursey <paul@decoursey.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: renaming columns
References: <200612291239.14515.ralf.wiebicke@exedio.com>
 <4595088F.5010804@sun.com> <200612291354.00191.ralf.wiebicke@exedio.com>
 <45954567.1000008@gmail.com>
In-Reply-To: <45954567.1000008@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stanley Bradbury wrote:
> Ralf Wiebicke wrote:
>>> Note that 10.2.2 is made from another svn branch than the development
>>> branch (trunk).  Revision numbers on different branches are not 
>>> directly
>>> comparable.      
> Hi Ralf -
> I'm glad to see that you are taking Derby for a test drive.  Being 
> included in latest JAVA release will  introduction Derby to a much 
> wider audience than ever before.  One thing that you and others will 
> notice about Derby is that it is not just a database of a different 
> color, notably it has a very small footprint and so lacks some 
> out-of-the-box features of larger, mainstream systems.  This can cause 
> some frustration.  A little background will help you understand and 
> possibly anticipate some of the differences between Derby and other 
> databases.  The software was first released in 1997 by Cloudscape Inc. 
> as a product called JBMS.  In his article / tutorial Pan Pantziarka 
> provides a brief history of the software at:    
> http://www.regdeveloper.co.uk/2006/11/08/java_database_derby/
>
> JBMS (later renamed Cloudscape) was designed primarily for embedded 
> use hence the lack of features (thought of as administrative) such as 
> RENAME, GRANT/REVOKE, etc.  The underlying engine, however, is very 
> solid and easy to deploy and use.  Currently many of these useful 
> features are being added by the Derby development community with 
> minimal impact of the software footprint.  And, as you can see from 
> the following list of software, Derby in it's current state is the 
> choice on many software projects because of it's portability and ease 
> of use in production environments:
>               http://wiki.apache.org/db-derby/UsesOfDerby
>
> In the meantime, even though these differences can prove frustrating, 
> I hope you will keep your eye on the product and provide additional 
> feedback on the features you consider important but lacking in Derby.
>
>
I personally don't mind the limitations and sometimes welcome them.  
They force me to be more forward thinking in my db design. And for most 
things Derby is perfect, I use it most often for quick prototyping and 
proof of concept builds. Then when it comes time to build out production 
systems I will often move to a larger Database product. I often find 
that Derby works fine even in production environments.  You just have to 
think ahead about what changes to the structure could happen down the road.

Paul