db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul J DeCoursey <p...@decoursey.net>
Subject Re: renaming columns
Date Fri, 29 Dec 2006 16:50:10 GMT
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


Mime
View raw message