Ratings and Reviews
Community Rating
Average Rating: 4.3/5.0Number of Ratings: 22Number of Reviews: 4
My Review of Apache Derby |
||
| You have not rated or reviewed this project.Click below to rate/review. | My Rating: | |
| New Review | ||
Most Helpful Reviews
The sign of a good embedded database system is not who’s running it, but rather who doesn’t know they’re running it! The ideal database is one that sits there in the background, working hard, and never raising a peep nor complaining. That’s Apache Derby!
We’ve been using Apache Derby as the default database for our print management application, PaperCut NG ( http://www.papercut.biz/ ), for 2 years now. Our software has been deployed by tens of thousands of organizations ranging from small schools all the way up to prestigious academic organizations and corporate banks. Although we offer the option to choose other external databases, the majority stick with Apache Derby as the embedded default. Many PaperCut NG installations handle thousands of print transactions a day and host datasets in the millions of rows. Apache Derby has proven that an embedded zero-administration database can be robust and scalable in a range of environments and operating systems.
At the technical level, PaperCut NG ships with Derby set up as a default meaning that users can use our system out-of-the-box without the need to undertake any DB setup tasks. We use Hibernate for OR mapping and Spring for transaction management. Apache Derby slotted into this environment without any problems.
We highly recommend Apache Derby (and so would our customers if they knew they were running it ;-).
Derby is an excellent embedded database when working with Java. I've worked on a project for over a year now that is using Derby in an embedded fashion. We use Derby embedded within a data profiling product. The purpose of the product is to help business users understand the nature of their data and also to audit data.
Derby is used as the container of data and the generated metrics. A Derby database is created for every execution and is populated by the engine that generates the metric results. The created database is queried when an end user clicks on a graph within a report. For example, if a user runs an equal range binning metric on a numeric field, the input data is binned into a fixed number of buckets. The population of each bucket is graphed and presented to the user. If the user clicks on a part of the graph (lets say bin 1), the Derby database is queried to find all rows that fall into that bin. The data is then displayed using a data browser.
The "drill down" feature of this product has been a very popular one with users and would have been much harder to create without Derby. The small footprint of Derby is amazing given the amount of functionality it provides. I highly recommend Derby for ease of use and true embed-ability.
I'm a relatively inexperienced programmer (< 2 years in Java), with absolutely no prior experience with database work at all. But derby has allowed me to easily get my feet wet in the database world without any major hassles.
I love the fact that it's written in java. Since I only have a Linux box to develop on, but must deploy for a Windows environment, simply being able to package derby.jar with my build and knowing that it will work is very handy.
Plus, OpenOffice and Netbeans both support it, which is handy.
Most Recent Reviews
I'm a relatively inexperienced programmer (< 2 years in Java), with absolutely no prior experience with database work at all. But derby has allowed me to easily get my feet wet in the database world without any major hassles.
I love the fact that it's written in java. Since I only have a Linux box to develop on, but must deploy for a Windows environment, simply being able to package derby.jar with my build and knowing that it will work is very handy.
Plus, OpenOffice and Netbeans both support it, which is handy.
Derby is an excellent embedded database when working with Java. I've worked on a project for over a year now that is using Derby in an embedded fashion. We use Derby embedded within a data profiling product. The purpose of the product is to help business users understand the nature of their data and also to audit data.
Derby is used as the container of data and the generated metrics. A Derby database is created for every execution and is populated by the engine that generates the metric results. The created database is queried when an end user clicks on a graph within a report. For example, if a user runs an equal range binning metric on a numeric field, the input data is binned into a fixed number of buckets. The population of each bucket is graphed and presented to the user. If the user clicks on a part of the graph (lets say bin 1), the Derby database is queried to find all rows that fall into that bin. The data is then displayed using a data browser.
The "drill down" feature of this product has been a very popular one with users and would have been much harder to create without Derby. The small footprint of Derby is amazing given the amount of functionality it provides. I highly recommend Derby for ease of use and true embed-ability.
We've been using Apache Derby embedded into rich clients we've been delivering to various customers. It is undeniable that it strength reside in being able to power any Java application, being it rich client, web application or others completely hidden from the user / installer.
It has been deployed together with a JPA implementation, fully enabling object oriented programming principles to developers. We've used it to distribute the persistence of server side entities to rich clients, enabling users to work offline and then resynchronize with the server as soon as a connection is again available.
Apache Derby has never let us down, providing incredible performances, especially embedded! Weird behavior was encountered due to JPA implementations, not Derby itself. To me it is just the proof of maturity level it has gained over the years. A level that widely used, but also younger framework haven't yet reached!
The sign of a good embedded database system is not who’s running it, but rather who doesn’t know they’re running it! The ideal database is one that sits there in the background, working hard, and never raising a peep nor complaining. That’s Apache Derby!
We’ve been using Apache Derby as the default database for our print management application, PaperCut NG ( http://www.papercut.biz/ ), for 2 years now. Our software has been deployed by tens of thousands of organizations ranging from small schools all the way up to prestigious academic organizations and corporate banks. Although we offer the option to choose other external databases, the majority stick with Apache Derby as the embedded default. Many PaperCut NG installations handle thousands of print transactions a day and host datasets in the millions of rows. Apache Derby has proven that an embedded zero-administration database can be robust and scalable in a range of environments and operating systems.
At the technical level, PaperCut NG ships with Derby set up as a default meaning that users can use our system out-of-the-box without the need to undertake any DB setup tasks. We use Hibernate for OR mapping and Spring for transaction management. Apache Derby slotted into this environment without any problems.
We highly recommend Apache Derby (and so would our customers if they knew they were running it ;-).