Related
First of all, I'm sorry for a long explanation.
I need to develop a desktop app that will enable users to enter patients lab results for tracking diabetes treatment.
I usually code in php/mysql, but I'm not allowed to use it (my first choice was to use LAMP / XAMPP, but was told not to do so). I was told to use MS Access, as the easiest tool, but since I've never used it before, it gave me a lot of headache. Its wizards are great, but I needed to use data from several tables in my forms, and was simply unable to efficiently do so.
So, here is my question: What sort of db can I use with Java to create such an Application? As I said, I'm most comfortable with PHP/MYSQL combination, but during my studies I also used Java quite a lot. If I could find some sort of 'template' for such an application, I could probably create this easily.
I found this http://netbeans.org/kb/docs/java/gui-db.html using google. How complicated is this?
I need to create this ASAP, since I need to get this App to a team of medical staff, since I need this data to use as datasets for my MSc thesis (related to case based reasoning). I'm really behind schedule here :). And someone will probably break my neck if I don't develop it in a few days and start working on a theoretical part of my thesis.
Thank you in advance.
Okay, this one is near and dear having just been diagnosed as pre-diabetic.
What's not completely clear from your description is if you are keeping a separate database for each instance of the app, or are you sharing the data in one big remote database?
And how much data are you expecting?
If it's just for each instance, then any old database will work; the lightest weight one is actually probably sqlite3, but since you're in a hurry and used to LAMP, mysql will certainly work.
For remote data, go with mysql.
Either way around, there are plenty of ways to connect to the database, most all of them based on JDBC. It seems like you basiucally need two tables: patient, and labs. Patient will be something like <name,dob,ssan,address>, and labs something like <ssan, labtype, value, units>. SSAN would be the key and a record would be something like
123-45-6789|A1C| 6.0|pct glucolated
In that case, I'd just make the tables, have two forms with the data, and don't try for anything too fancy.
Update
Okay, from your comments, yes, either use Derby or just use text files. Do you need any particularly complicated queries? In the Old Days we would just have made something like a CSV file and read it into memory.
Oh, and look into Java Web Start for distributing the app.
You can use Java to connect to a database via JDBC. Check out this tutorial. http://download.oracle.com/javase/tutorial/jdbc/index.html. You can use mySQL as your database. You can also use embedded databases such as derby which don't require an external database application.
Here are 2 tutoriala how to build CRUD application on top of the NetBeans Platform (a Swing-based RCP):
http://platform.netbeans.org/tutorials/nbm-maven-crud.html
http://platform.netbeans.org/tutorials/nbm-crud.html
I have data that is streamed from disk and processed in memory by a Java application and that finally needs to be copied into SQL Server. The data can be fairly large (hence the streaming) and can require up to several 100,000 rows to be inserted. The fastest solution seems to be using SQL Server's bulk-copy feature. However, I haven't found any way for Java programs to do this easily or nearly fast enough.
Here are some ways that I've already investigated:
Using the SqlBulkCopy class in .NET. This is very efficient since you can stream data right from a data source and straight to SQL Server. The problem with this approach is that you need to be running .NET. Perhaps this could be used using a Java to .NET bridge. Although, I wonder about the cost of marshalling data between runtimes.
Using the BULK INSERT TSQL statement. The problem with this is that you need create a properly formatted file on disk. I've seen some small performance gains over JDBC's batch insert using this. Also, this is only useful locally.
Write files to disk and use the bcp command line utility. Still a little faster than JDBC batch insert but not that much. I also lose the ability to use a transaction with this method.
Use the C API. Again, very efficient, but you need to be using C. There would be a way to use this through JNI. If there's some free Java library out there that does this, I'd like to know about it.
I'm looking for the fastest solution. Memory is not an issue.
Thanks!
For the .NET answer i would recommended IKVM. Then your Java Code will be .NET code and you can call any .NET code.
The BULK INSERT required also that the bulk file is accessible from SQL Server. This is only a local option. The performance from Batch Update can be vary between different JDBC drivers.
For native calls I would recommended to use JNA (Java native access). Then you does not need to write any C code.
The best option for me was to use the commercial SQL Server JDBC driver from DataDirect with standard JDBC calls addBatch/executeBatch that run across Linux and Windows - https://blogs.datadirect.com/2012/05/how-to-bulk-insert-jdbc-batches-into-microsoft-sql-server-oracle-sybase.html
I've seen load times improve from 7 hours to under 30 minutes.
Since version 4.2 of the Microsoft JDBC driver for SQL Server, there is a class named com.microsoft.sqlserver.jdbc.SQLServerBulkCopy which does the same as the SqlBulkCopy class of .NET.
I'm working on a small (java) project where a website needs to maintain a (preferably comma-separated) list of registered e-mail addresses, nothing else, and be able to check if an address is in the list. I have no control over the hosting or the server's lack of database support.
Prevayler seemed a good solution, but the website is a ghost town, with example code missing from just about everywhere it's supposed to be, so I'm a little wary.
What other options are recommended for such a task?
Use an embedded database like HSQLDB, H2 or Derby/JavaDB. They need no installation and can use simple files as their storage mechanism.
Yeah, prevayler and its historical concurrent, space4j, are really good candidates for such a simple case. They're far simpler than DB, provides however some useful concepts and are way fast (since in fact FS is only a backup of the in-memory datastore.
You may want to consider Berkeley DB.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I intend to develop a small (Java) application for managing my finances. I believe I need to use an embedded database, but I have no experience regarding this issue. I tried to look at some of the available products, but I can't decide which one would be more suitable for me. H2, HSQLDB, Derby and Berkeley DB seem to be good candidates, but I still don't see how they compare to each other. I appreciate your help comparing them and helping me decide which one to use.
I intend to use Hibernate for my application (unless you would recommend using DBMS-provided API), but I also want to have the ability to edit the database easily using a SQL browsing tool (modifying schema and changing data).
Thank you.
Either
HSQLDB - Used by OpenOffice, tested and stable. It's easy to use. If you want to edit your db-data, you can just open the file and edit the insert statements.
or
H2 - Said to be faster (by the developer, who originally designed hsqldb, too)
Which one you use is up to you, depending how much performance and how much stability you need.
The developer of H2 has put up a nice performance evaluation:
http://www.h2database.com/html/performance.html
I use Apache Derby for pretty much all of my embedded database needs. You can also use Sun's Java DB that is based on Derby but the latest version of Derby is much newer. It supports a lot of options that commercial, native databases support but is much smaller and easier to embed. I've had some database tables with more than a million records with no issues.
I used to use HSQLDB and Hypersonic about 3 years ago. It has some major performance issues at the time and I switch to Derby from it because of those issues. Derby has been solid even when it was in incubator at Apache.
I needed to use Java embedded database in one of my projects and I did lot of research understanding pros and cons of each database. I wrote a blog listing pros and cons of popular embedded java databases (H2, HSQLDB, Derby, ObjectDB, Neo4j, OrientDB), you can have a look at it. I chose H2 as I thought it best suited my requirements.
Link for the blog: http://sayrohan.blogspot.in/2012/12/choosing-light-weight-java-database.html
Hope it helps!
I'd go with H2, the performance is meant to much better than Derby. Read http://www.h2database.com/html/performance.html for more info.
HSQLDB is a good candidate (the fact that it is used in OpenOffice may convinced some of you), but for such a small personnal application, why not using an object database (instead of a classic relationnal database) ?
I used DB4O in one of my projects, and I'm very satisfied with it. Being object-oriented, you don't need the whole Hibernate layer, and can directly insert/update/delete/query objects ! Moreover, you don't need to worry about the schema, you directly work with the objects and DB4O does the rest !
I agree that it may take some time to get used to this new type of database, but check the DB40 tutorial to see how easy it makes working with the DB !
EDIT: As said in the comments, DB4O handles automatically the newer versions of the classes. Moreover, a tool for browsing and updating the database outside of the application is available here : http://code.google.com/p/db4o-om/
Java DB (Sun's distribution of Apache Derby) now ships in JDK 6!
I've been wanted to do something like Jason Cohen and have been thinking this looks like the easiest way being in the JDK distro (which of last week is now a requirement for my app). Or maybe I am just lazy that way.
We use HSQLDB in production as a "no-configuration" option for our application. It allows people to trial without the hassle of setting up a real database.
However we do not support it for normal use. The reasons are several:
Slows down proportionally to the size of the data.
Difficult to access outside of our app (e.g. for custom reports).
Transactions / disk-sync is difficult to get right, so it's easy to lose data.
For at least (2) and (3), there are ways around it but it's difficult; it's much easier to e.g. install MySQL.
neo4j is:
an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables
I haven't had a chance to try it yet - but it looks very promising. Note this is not an SQL database - your object graph is persisted for you - so it might not be appropriate for your existing app.
HSQLDB may cause problems for large applications, its not quite that stable.
The best I've heard (not first hand experience however) is berkleyDB. But unless you opensource it, it will cost you an arm and a leg to use due to licensing...see this http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html for details.
ps. berkleyDB is not a relational database in case you didnt know.
Good comparison tool can be found here: http://www.jpab.org/All/All/All.html
Notice also the Head to Head DBMS/JPA Comparisons
Most things have been said already, but I can just add that I've used HSQL, Derby and Berkely DB in a few of my pet projects and they all worked just fine. So I don't think it really matters much to be honest. One thing worth mentioning is that HSQL saves itself as a text file with SQL statements which is quite good. Makes it really easy for when you are developing to do tests and setup data quickly. Can also do quick edits if needed. Guess you could easily transfer all that to any database if you ever need to change as well :)
I am a big fan of DB4O for both .Net and Java.
Performance has become much better since the early releases. The licensing model isnt too bad, either. I particularly like the options available for querying your objects. Query by example is very powerful and easy to get used to.
What criteria will you use to evaluate these ? If you don't know yet, then you don't need to decide right now. Try to make your application as database-implementation-agnostic as you can - providing the appropriate wrappers, data access objects etc., and make this decision when you have all the facts to hand and you have to decide.
If you're using relational databases and SQL then the above shouldn't be too hard (using JDBC etc). Make sure you have plenty of surrounding tests so that when you want to switch between databases, you can determine that your application's functionality remains the same.
I ran into the same issue some time ago. I didn't know which database to go for, so my first solution used Derby (or HSQLDB?), and I was later able to switch to HSQLDB (or Derby ? Can't remember which solution worked) once I'd determined where I had issues (relating to performance) and which solution would really work for me.
I have used Derby and i really hate it's data type conversion functions, especially date/time functions. (Number Type)<--> Varchar conversion it's a pain.
So that if you plan use data type conversions in your DB statements consider the use of othe embedded DB, i learn it too late.
Latest Derby Version data type conversions
I personally favor HSQLDB, but mostly because it was the first I tried.
H2 is said to be faster and provides a nicer GUI frontend (which is generic and works with any JDBC driver, by the way).
At least HSQLDB, H2 and Derby provide server modes which is great for development, because you can access the DB with your application and some tool at the same time (which embedded mode usually doesn't allow).
I guess I'm a little late (a lot late;-)) to this post, but I'd like to add Perst, an open source, object-oriented embedded database for Java &.NET. for your consideration. Perst is an open source / dual license embedded database for Java. The distribution is compatible with Google's Android platform, and also includes Perst Lite for Java ME. We've even built an Android benchmark and produced a whitepaper on the subject...you can take a look here: http://www.mcobject.com/index.cfm?fuseaction=download&pageid=581§ionid=133
All the best,
Chris
If I am correct H2 is from the same guys who wrote HSQLDB. Its a lot better if you trust the benchmarks on their site. Also, there is some notion that sun community jumped too quickly into Derby.
I realize you mentioned SQL browsing, but everything else in your question makes me want to suggest you also consider DB4O, which is a great, simple object DB.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I intend to develop a small (Java) application for managing my finances. I believe I need to use an embedded database, but I have no experience regarding this issue. I tried to look at some of the available products, but I can't decide which one would be more suitable for me. H2, HSQLDB, Derby and Berkeley DB seem to be good candidates, but I still don't see how they compare to each other. I appreciate your help comparing them and helping me decide which one to use.
I intend to use Hibernate for my application (unless you would recommend using DBMS-provided API), but I also want to have the ability to edit the database easily using a SQL browsing tool (modifying schema and changing data).
Thank you.
Either
HSQLDB - Used by OpenOffice, tested and stable. It's easy to use. If you want to edit your db-data, you can just open the file and edit the insert statements.
or
H2 - Said to be faster (by the developer, who originally designed hsqldb, too)
Which one you use is up to you, depending how much performance and how much stability you need.
The developer of H2 has put up a nice performance evaluation:
http://www.h2database.com/html/performance.html
I use Apache Derby for pretty much all of my embedded database needs. You can also use Sun's Java DB that is based on Derby but the latest version of Derby is much newer. It supports a lot of options that commercial, native databases support but is much smaller and easier to embed. I've had some database tables with more than a million records with no issues.
I used to use HSQLDB and Hypersonic about 3 years ago. It has some major performance issues at the time and I switch to Derby from it because of those issues. Derby has been solid even when it was in incubator at Apache.
I needed to use Java embedded database in one of my projects and I did lot of research understanding pros and cons of each database. I wrote a blog listing pros and cons of popular embedded java databases (H2, HSQLDB, Derby, ObjectDB, Neo4j, OrientDB), you can have a look at it. I chose H2 as I thought it best suited my requirements.
Link for the blog: http://sayrohan.blogspot.in/2012/12/choosing-light-weight-java-database.html
Hope it helps!
I'd go with H2, the performance is meant to much better than Derby. Read http://www.h2database.com/html/performance.html for more info.
HSQLDB is a good candidate (the fact that it is used in OpenOffice may convinced some of you), but for such a small personnal application, why not using an object database (instead of a classic relationnal database) ?
I used DB4O in one of my projects, and I'm very satisfied with it. Being object-oriented, you don't need the whole Hibernate layer, and can directly insert/update/delete/query objects ! Moreover, you don't need to worry about the schema, you directly work with the objects and DB4O does the rest !
I agree that it may take some time to get used to this new type of database, but check the DB40 tutorial to see how easy it makes working with the DB !
EDIT: As said in the comments, DB4O handles automatically the newer versions of the classes. Moreover, a tool for browsing and updating the database outside of the application is available here : http://code.google.com/p/db4o-om/
Java DB (Sun's distribution of Apache Derby) now ships in JDK 6!
I've been wanted to do something like Jason Cohen and have been thinking this looks like the easiest way being in the JDK distro (which of last week is now a requirement for my app). Or maybe I am just lazy that way.
We use HSQLDB in production as a "no-configuration" option for our application. It allows people to trial without the hassle of setting up a real database.
However we do not support it for normal use. The reasons are several:
Slows down proportionally to the size of the data.
Difficult to access outside of our app (e.g. for custom reports).
Transactions / disk-sync is difficult to get right, so it's easy to lose data.
For at least (2) and (3), there are ways around it but it's difficult; it's much easier to e.g. install MySQL.
neo4j is:
an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables
I haven't had a chance to try it yet - but it looks very promising. Note this is not an SQL database - your object graph is persisted for you - so it might not be appropriate for your existing app.
HSQLDB may cause problems for large applications, its not quite that stable.
The best I've heard (not first hand experience however) is berkleyDB. But unless you opensource it, it will cost you an arm and a leg to use due to licensing...see this http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html for details.
ps. berkleyDB is not a relational database in case you didnt know.
Good comparison tool can be found here: http://www.jpab.org/All/All/All.html
Notice also the Head to Head DBMS/JPA Comparisons
Most things have been said already, but I can just add that I've used HSQL, Derby and Berkely DB in a few of my pet projects and they all worked just fine. So I don't think it really matters much to be honest. One thing worth mentioning is that HSQL saves itself as a text file with SQL statements which is quite good. Makes it really easy for when you are developing to do tests and setup data quickly. Can also do quick edits if needed. Guess you could easily transfer all that to any database if you ever need to change as well :)
I am a big fan of DB4O for both .Net and Java.
Performance has become much better since the early releases. The licensing model isnt too bad, either. I particularly like the options available for querying your objects. Query by example is very powerful and easy to get used to.
What criteria will you use to evaluate these ? If you don't know yet, then you don't need to decide right now. Try to make your application as database-implementation-agnostic as you can - providing the appropriate wrappers, data access objects etc., and make this decision when you have all the facts to hand and you have to decide.
If you're using relational databases and SQL then the above shouldn't be too hard (using JDBC etc). Make sure you have plenty of surrounding tests so that when you want to switch between databases, you can determine that your application's functionality remains the same.
I ran into the same issue some time ago. I didn't know which database to go for, so my first solution used Derby (or HSQLDB?), and I was later able to switch to HSQLDB (or Derby ? Can't remember which solution worked) once I'd determined where I had issues (relating to performance) and which solution would really work for me.
I have used Derby and i really hate it's data type conversion functions, especially date/time functions. (Number Type)<--> Varchar conversion it's a pain.
So that if you plan use data type conversions in your DB statements consider the use of othe embedded DB, i learn it too late.
Latest Derby Version data type conversions
I personally favor HSQLDB, but mostly because it was the first I tried.
H2 is said to be faster and provides a nicer GUI frontend (which is generic and works with any JDBC driver, by the way).
At least HSQLDB, H2 and Derby provide server modes which is great for development, because you can access the DB with your application and some tool at the same time (which embedded mode usually doesn't allow).
I guess I'm a little late (a lot late;-)) to this post, but I'd like to add Perst, an open source, object-oriented embedded database for Java &.NET. for your consideration. Perst is an open source / dual license embedded database for Java. The distribution is compatible with Google's Android platform, and also includes Perst Lite for Java ME. We've even built an Android benchmark and produced a whitepaper on the subject...you can take a look here: http://www.mcobject.com/index.cfm?fuseaction=download&pageid=581§ionid=133
All the best,
Chris
If I am correct H2 is from the same guys who wrote HSQLDB. Its a lot better if you trust the benchmarks on their site. Also, there is some notion that sun community jumped too quickly into Derby.
I realize you mentioned SQL browsing, but everything else in your question makes me want to suggest you also consider DB4O, which is a great, simple object DB.