Thanks for this great presentation, Matt. Slide 8 is a terrific diagram
of Derby's sweet spot.
Regards,
-Rick
Matt Doran wrote:
Hi All,
I recently did a presentation about Apache Derby at the Australian
Java User's Group meeting in Melbourne. The presentation was titled
"Using Apache Derby in the real world". Its focus was not so much on
how to use Derby, but were it can be used and how it stands up in real
world applications. We use Derby in our print accounting application
called PaperCut, and feel that it's one of the "gems" of the Java
community. Even thought we offer a choice of MS SQL Server, Oracle
and Postgres within PaperCut, we find that 90% of our 10,000+ users
stick with Derby - the default embedded option. The presentation
highlighted this as well as gave an overview of the idiosyncrasies and
system performance tweaks we've made over the years.
I thought I'd shared the presentation with the list as some of the
content might be useful if others want to present Derby at their local
JUG!
PDF:
http://www.papercut.com/anonftp/pub/open-source/apache-derby/ApacheDerbyAJUGPresentation.pdf
HTML:
http://docs.google.com/Present?docid=dcz4c74g_82nr92vgnt&skipauth=true
<http://docs.google.com/Present?docid=dcz4c74g_82nr92vgnt&skipauth=true>
The presentation also proposes a few potential ideas for future
features. That is, moving more towards zero administration, and a
better out-of-the-box experience for all application domains.
We think Derby's best "feature" is it's wide domain of applicability -
that is it can be used from anywhere from say a very small embedded
database like say SQLite, all the way up to concurrent database
applications matching MySQL, etc. We've found that the default
configuration options are however stacked in favor of the "small
embedded" use case, and some manual performance tuning is required to
get performance up on large datasets and more complex queries. It
would be great if the out-of-the-box domain of applicability was as
wide as possible and one idea presented to achieve this is the concept
of profiles. For example, a profile parameter could be added to the
current JDBC connection string and this could be used to reconfigure
defaults more appropriate for the usage domain.
Hope the Derby enthusiasts find this information useful.
Kind Regards,
--
Matt Doran
PaperCut Software Int. Pty. Ltd.
Profile: http://www.papercut.com/about/#matt
Weblog: http://www.papercut.com/blog/
