The open source Derby database engine provides developers with a powerful new tool for lightweight database development. Derby databases are file system based and portable across different types of systems. Because of this, a common strategy is to create databases at development time and ship them with the binary distribution as opposed to having it created on the fly.
Derby database development with Apache Ant
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Does anyone know how this compares to SQLLite or BerkleyDB ?
AFAIK SQLLite is not java-based and BerkleyDB is not relational. I’d be interested to know how Derby compares to this project http://hsqldb.sourceforge.net/
http://sqlite.org presents a fairly SQL92 compliant library coded in C.
The library itself weighs in ~200k, making the idea of lighting off an in-RAM database feasible, for reasonable values of ‘small’. Bring your own type system, however.
I think that, from the article, Apache Ant is one of those rare tools that every developer must absolutely have in their development toolkit. gets the “Ahem” award for the day, and serves to crush interest in further investigation.
SQLLite is not a good choice for java developers. there are other databases available. They are pure java and can work as embedded and server. i believe they are better choices comparing to sqllite. they have better SQL compliance and jdbc support (i am not sure if SQLLite has jdbc support at all) . Such as HSQLDB, Mckoi and Daffodill 1$DB. Derby is the new player.
“Derby databases are file-system based, Only one instance of Derby is allowed to be loaded per instance of the Java Virtual Machine (JVM), and only a single Derby instance is allowed to access any given database at a time.”
– in other words, the use of a Derby database is relegated to a single executable instance (or many users lined up serially using the same application).
> – in other words, the use of a Derby database is relegated
> to a single executable instance (or many users lined up
> serially using the same application).
I don’t believe this is exactly what it means. Generally this means that only a single instance of the database can use the data files simultaneously. It implements a threading server for concurrent access, though (or at least Cloudscape used to).
Of course, it is so slow as to make that almost useless.
SQLLite is not a good choice for java developers. … (i am not sure if SQLLite has jdbc support at all)
Props for the self-rebutting comment.
your point?
From the sqlite website, there is Java support for sqlite, both JDBC and SWIG. JDBC is here: http://www.ch-werner.de/javasqlite
HTH
As it seems JDBC support is not from the SQLlite developers. No wonder i couldnt find it in the original site. This is rather a wrapper for the older version and JDBC support is not as complete as the java DB contenders, such as Hsqldb. SQL compatibility is another losing point.
The point being made is that you were not sure if sqllite has JDBC support, yet you were able to conclude that it is not a good choice for java developers.
Personally I am with you, I don’t think you have to know if it has jdbc support or not to know that there are better options for java developers.
Thank you.
And yes, if you’re using J2EE at all, you probably need some bigger iron in the database department.
Which is not to say that, even in your full-on application, just a pinch of Dr. Hipp’s finest might not hit the spot.
HSQLDB is the embedded DB to beat. Derby’s performance is nowhere near what HSQLDB can provide, and quite simply it’s main downfall. Maybe a few more dev milestones down the line Derby will improve – but I right now wouldn’t consider using it in production level projects even if you paid me.