Creating a new local database with Java - java

My aim is to create a local database that can be read and written to with Java. I have some experience with manipulating a local sqlite database with Python, and with interacting with existing networked databases on Microsoft Azure via VB.Net, but the Java formulation for creating a database is escaping me.
Most sources (like the JDBC Docs) seem to assume that you are accessing a database through a network protocol, or a database hosted on localhost. My desired implementation is to create and store the database in a file (or collection of files), so that it can be stored and accessed locally, without network connectivity (presumable through the "file:" protocol).
The JDBC Tutorial looks like it will be very useful once I am up and running, but is currently beyond my scope, since I don't even have an existing database yet.
Many sources have suggested solutions like H2, MySQL, Derby, or Hypersonic DB. However, I'm loath to install extensions (if that's the right term) for a number of reasons:
This project is initially intended to help me learn my way around Java - widening the scope of the project will dilute my experience with the "base" language and, probably, increase the temptation to engage in "cargo cult programming"
If this project does ever get distributed to other users (admittedly unlikely, but still!), I don't want to force them into installing more than the core of Java.
I simply don't know how to install extensions (add-ons? modules?) in Java - one baby-step at a time!
For similar reasons, installing Microsoft SQL Server would not be productive.
This answer looks close to what I'm aiming for; however, it gives the error:
java.sql.SQLException: No suitable driver found for jdbc:mysql://localhost/?user=root&password=rootpassword
and trying "jdbc:file://targetFile.sql" gives a similar error.
I've seen the term "embedded" database, which I think is a subset of "local database" (i.e. a local database is stored on the same system - an embedded database is a local database that is only used by a single application) - if I've got those definitions wrong, please feel free to correct me!

Most likely, the reason for which you are getting the error, is due to the fact that you are not registering the driver (using reflection...) before actually using it for establishing a connection and so on.
Presumably you will want to do something along the lines of Class.forName("driver")
and then cast that if necessary and then registering it in the DriverManager before calling the getConnection() method.
Here is a very useful link that might help you out in solving the issue:
http://www.kfu.com/~nsayer/Java/dyn-jdbc.html
However, if you really want to use a local database/file you might want to have a look at SQLite, that might be one way to go about it, although I recommend going for the MySQL approach, as it is a lot easier to configure and learn how stuff works with JDBC.
If you are still considering SQLite check this out:
Java and SQLite
I see you need some guidance in importing external .jar files into your code (i.e. 3rd party libraries like the ones you will be using for a JDBC driver). Are you using an IDE (e.g. Eclipse, Netbeans, etc.) or are you writing in a text editor and compiling manually?

A number of embedded pure Java databases appeared recently, which have a really simple interface, usually just java.util.Map, don't involve using JDBC or other SQL artifacts, and store their data in a single file or directory:
Chronicle Map
JetBrains Xodus
MapDB
The main downside is that most of such databases provide only the simples key-value model.

DBC can be used with any database that has a JDBC driver, which isn't necessarily a database in "network mode", it can be used with embedded databases as well.
Here are some Java and embeddable databases:
http://www.h2database.com/html/main.html
http://db.apache.org/derby/
http://hsqldb.org/

Java's JDK does not include any implementation of a database nor drivers to access it. It only provides JDBC as an abstraction to connect to a "database". Is up to you to include all the needed libraries in your code.
If you want to have a self contained code you can simply include the .jar file of a embeddable database in you classpath. That way you can create the instance of the database in your code and minimize the external dependencies.
You can find here a list of java embeddable databases
You can find here an example of how to embed HSQLDB in your code.

Related

What's the recommended way to migrate from H2 1.3.175 to 1.4.195

Now that H2 1.4 is out of beta, I'd like to migrate my old 1.3.175 database to 1.4.195.
Background info:
In the docs, database upgrade does not mention 1.4 yet.
The roadmap still lists "Automatic migration from 1.3 databases to 1.4." as "planned change".
The current state of MVStore is still labeled as "experimental".
So, what's the recommended way to migrate?
Additional aspects/bonus questions:
Should I enable MVStore or stick with PageStore (pros/cons)? Which one delivers better performance (multithreading is not important for me), which one better stability, especially resilience against OutOfMemoryErrors?
A database created with 1.3.175 can be read and opened with 1.4.195 without any additional work. H2 will automatically detect that it is using the Page Store and treat it as such. There will be no problems with doing this.
The advantage to doing this is that while the MVStore was being developed, the Page Store continued to receive performance improvements and bug fixes. Consequently H2 with the Page Store has become an extremely stable database store.
There is as yet no automatic upgrade procedure for converting a database from using the Page Store to using the MVStore. If you do want to do this, you'll need to do it manually. With the latest H2 Jar, use H2's SCRIPT command to export SQL from your 1.3 database, then use RUNSCRIPT into a freshly created db with 1.4.195.
If your H2 JDBC URL doesn't explicitly specify ;mv_store=false, note that H2 will first look to see if a page store database already exists. If it doesn't then it will create an MVStore database. This will appear seamless to you, your app, and your users. The only superficial difference you'll notice is that the database file on disk has a different file extension.
Finally, a suggestion. If your customer databases are large, consider only using the page store. I'm a heavy user of H2. (My commercial product built on H2 has thousands of users who typically have databases many gigabytes in size.) I still use the page store for all my customers, even though I use the latest H2 Jar. There are still some performance issues with the MVStore that start to appear as databases get large. With time, I expect the cause of the problems to be identified and fixed.
#Steve McLeod's answer is on point. For completeness, here are the exact commands:
//Do a backup of current .h2.db file
//Connect to current DB with same URL as always
SCRIPT TO 'fileName'
//Rename the .h2.db to something else, possibly another backup
//Connect to database with same URL as before. The new MVStore engine will be chosen by default, and the .mv.db file will be created
RUNSCRIPT FROM 'fileName'
Documentation, H2 Grammar
Moreover, if you prefer using the H2 jar for this, refer to Thomas's answers (1 and 2). Concretely, the corresponding classes are org.h2.tools.Script and org.h2.tools.RunScript
To highlight another alternative for similar requests I would like to mention a tool which allows an automatized migration of an old H2 database into a new H2 database:
https://github.com/manticore-projects/H2MigrationTool

Java Netbeans Derby database for embedded system dilema: create the database with Netbeans or with code?

I read a lot of posts like:
querying embedded database in netbeans using derby
But still I'm having trouble to understand embedded databases.
1) I create a Derby database on Netbeans and I can create tables, link the database to a form and submit the data and update the records with no problem.
2) The problem arises when I want to make the program portable. I apply Clean and Build, then copy the dist folder and also copy the libraries, database, etc ... but when running the program does not recognize the database
3) I read in several places that it is appropriate that the database is created by code using something like
String host = "jdbc: derby: // localhost: 1527 / EmployeesCreateTrue; create = true"
and not creating the database on Netbeans Service...
If I do this procedure with code the database is created but it does not appear or does not allow me to connect from NetBeans and I wish I could fix it to create tables from NetBeans and not from code.
4) I read manuals "how to import a database from Derby to NetBeans" and it doesn't work...
Question: What is the best way to create a database, tables and connect to NetBeans for the final application to be easily portable?
1) Create the database on Netbeans with the wizzard?
or
2) Just plain code on the application?
I don't understand precisely what you mean by "the database is created but it does not appear."
I think if you were to explain that precisely, the community could probably help you.
There are three common reasons for "table does not exist" when you think you've created the tables; I've explained those cases in this answer: Is it necessary to create tables each time you connect the derby database?
Please let us know more information about your situation so that we can help you better understand the behavior of your application.
I'm not 100% sure if this is your problem, but a lot of problems people seem to have with Netbeans and Derby seems to come from the fact that they don't set derby.system.home explicitly. When you don't, Derby stores databases in the current directory, and that is likely different when working in the IDE, either in the Services tab, or your own code, than when you execute your app's jar as a standalone program. So the advice (which you will also find in the manual) is: always set derby.system.home. An alternative would be to use full paths to the databases, but that rarely works well for a real application that is deployed on different machines.
I had the same problem --had the derby db in the services but the netbeans coded programs didn't access it. I solved it by adding the derby database (copy paste) to the package in the Files section. I use Windows 7. Once I did that, I was able use multiple tables (before netbeans just ignored secondary tables and only allowed me to use the primary table).

How to add mysql database into project setup.?

i have a java project with mysql database
i am using advance installer to create a setup file...
i can embed jre to run the software(Without installing java in the system).
like wise,i want to embed the mysql database (system doesn't contains mysql )...
.There is any software to embed mysql database in my project setup...
MySQL is very difficult to embed correctly and there are a number of failure states that might occur if it is not shut down using the proper procedure. SQLite is a much better engine for this sort of thing and is used by a number of applications as a persistent backing store. While not as powerful as MySQL, it is much more resilient. It also has the advantage of not requiring a separate process.
SQLite's storage method is to persist things into a file that can be copied, moved, or backed-up without any issues. MySQL involves many such files, some of which are in an inconsistent state unless the correct FLUSH is called.
The best you can do with MySQL is bundle it, not embed it, but then you'll be responsible for setting it up on the host system, configuring it correctly, running the appropriate maintenance procedures, and providing some kind of back-up facility for the database itself.

The simplest Java SQL provider?

I need SQL functionalities for a Java JSE application, but dont need a whole SQL server, with things like listen on a port, connection string or even a standalone process to be runned or configured.
I also would prefer to work with files as storages, so that file path identifies DB data.
So given to the DB API the name of a file, I would need perform SQL with the file as DB storage, supporting tables, search, joins and inserts, without thinking to things like ports, external processes, server installation, ecc..
Without any other configurration action, since any other configurable feature is not needed.
Is there some library, preferrably installable as single .jar, that provides this functionality?
If there is not this library, which file-based DB is the simplest to configure and use within JSE, and which configuration steps are needed to perform a query in the provided DB and deploy it with (working) the java .jar application?
I suggest Derby db.apache.org/derby/
I like H2 Database very much. It compares very well with other database engines.
Sure, Hypersonic SQL or Derby, the database that comes bundled with Java 7, will both fill the bill. SQLite would be a third alternative.
you may want to check this out:
http://www.sqlite.org/
I have used HSQLDB in the past and liked it. Depending on what your needs are, you might also be interested in JoSQL which allows you to do SQL type of queries on java collections.

Is it good practice to package an SQL database inside a JAR?

I would like to create a Java library without any dependency, but it needs to use an embedded SQL database. Is it good practice to package both the binary database file and the driver to access it inside the JAR file? What are some advantages and disadvantages?
HSQLDB
More and more Java applications have their own 'in-memory' database that is launched upon application start. Check out hsqldb for an example.
Most obvious advantage is that you control the database and don't have to take different DB servers and their sql dialects into account.
Go on, it's a widely adopted practice used by Hibernate for example.
For a memory constrained devices:
Then do not use embedded database at all. Try using ThoughtWorks library XStream which serializes/deserializes objects to XML/jSon which can be stored in files. Very effective solution with a small memory foot print.
Your database will be read-only (since you cant repackage the jar at runtime). If that is fine then go nuts :)

Categories

Resources