One of the interesting things about the Apache Derby database is that it's often the first database that a beginning programmer is exposed to.
One of the reasons for this is the wide distribution of Derby:
- It's free, and open source
- It's the most prominent database in the Apache Software Foundation (although it may be losing that place as other databases are added to the Apache umbrella
- It's included as part of the JDK download from Sun/Oracle
- It's bundled and embedded inside the NetBeans IDE from Sun/Oracle
- It's bundled and embedded inside the Glassfish application server from Sun/Oracle
For whatever reason, it seems quite common that new programmers, just beginning to get into the "serious" phase of the programming education, often come across Derby very early in their exposure to databases.
For this reason, I think that it's a very good thing that Derby is quite careful about the database implementation that it provides.
The Derby implementation of SQL is very traditional; it conforms quite tightly to the international SQL standards and behaves in the most correct manner in its implementation.
This gets programmers off to a good start.
Later, when they are more fluent in database concepts, have built some database applications, and are no longer struggling with the basic ideas, they can move on to other database implementations and start experimenting with variations and embellishments.
But there is a very long ways you can go while still adhering to the core SQL standards, and the knowledge you gain while working with Derby will be transferable to all those other wacky not-quite-standard databases you'll meet out there in the real world.
So the next time you wonder why the Derby developers are a bit touchy when they get asked why Derby doesn't implement your favorite database's Wacky Feature #39, remember that Derby is often software for beginners.
And beginners need to get off to a good start.