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.


View raw message