Java database

[richnjones]

Hi all

Is there a database I can use with my java application that does not
"install" on a user's PC?

To give more details....

The java program will be "installed" on the client PC by unzipping a
file. There will then be an executable jar for the user to click on.
The user will be able to decide where to place the extracted files
themselves. There will be no communication with the registry or
shortcut generation. (I think Eclipse does something similar). Now
this program needs to have a persistence layer. The requirement is
ideally for a database. Now I want to be able to use a database that
does not install on the computer. Does one exist? In other words one
that I can just open without it doing any installation. I am using
Windows.

Thanks in advance!

 

[Alexander Cherednichenko]

Hello!

If I understood you right, the thing you are searching for is called
embedded database.
It is simple a library, formed as jar, that you link to your project
and get local database capabilities.

I hope, this http://db.apache.org/derby/papers/DerbyTut/embedded_intro.html
would help.
Also, I have met Valentina Database - which can be used as embedded.
And found it quite interesting. It is not java, but it is cross-
platform, and allows some helpful things like database file
encryption. We have used Valentina as server, not embedded, so I am
not sure if info is relevannt, but Valentina is distributed
embeddable, that's true.

Here the link goes: http://www.paradigmasoft.com/

Alex.

 

[Arne Vajhøj]

Is there a database I can use with my java application that does not
"install" on a user's PC?

To give more details....

The java program will be "installed" on the client PC by unzipping a
file. There will then be an executable jar for the user to click on.
The user will be able to decide where to place the extracted files
themselves. There will be no communication with the registry or
shortcut generation. (I think Eclipse does something similar). Now
this program needs to have a persistence layer. The requirement is
ideally for a database. Now I want to be able to use a database that
does not install on the computer. Does one exist? In other words one
that I can just open without it doing any installation. I am using
Windows.

There are several such databases.

HSQLDB (very widely used in many server products and in OpenOffice),
Derby (ships with Java 1.6 as Java DB) etc..

Arne

 

[pcspecialist9]

There are several such databases.

HSQLDB (very widely used in many server products and in OpenOffice),
Derby (ships with Java 1.6 as Java DB) etc..

Arne

This database works perfectly.
It is a start!

http://www.ljaranet.com

 

[David Segall]

Hi all

Is there a database I can use with my java application that does not
"install" on a user's PC?

To give more details....

The java program will be "installed" on the client PC by unzipping a
file. There will then be an executable jar for the user to click on.
The user will be able to decide where to place the extracted files
themselves. There will be no communication with the registry or
shortcut generation. (I think Eclipse does something similar). Now
this program needs to have a persistence layer. The requirement is
ideally for a database. Now I want to be able to use a database that
does not install on the computer. Does one exist? In other words one
that I can just open without it doing any installation. I am using
Windows.

I have a list of candidates at
<http://database.profectus.com.au/#java>. Unless you have a compelling
reason to choose something else I would go for Derby/JavaDB. If you
are using the latest JDK you already have it.

 

[richnjones]

I have a list of candidates at
<http://database.profectus.com.au/#java>. Unless you have a compelling
reason to choose something else I would go for Derby/JavaDB. If you
are using the latest JDK you already have it.

Thanks for the replies. After looking at the different options I think
I'll go with Derby. i was very tempted by the good speed reports of
HSQL but I have not necessarily got loads of memory to play with so
Derby seems to suit my needs best
Thanks again!

 

[Thomas Kellerer]

Arne Vajhøj wrote on 25.01.2008 03:39:

There are several such databases.

HSQLDB (very widely used in many server products and in OpenOffice),
Derby (ships with Java 1.6 as Java DB) etc..

And then there is H2 (www.h2database.com) which is maintained by the initial
developer of HSQLDB and seems to have more momentum than HSQL currently.

Thomas

 

[Lew]

Thanks for the replies. After looking at the different options I think
I'll go with Derby. i was very tempted by the good speed reports of
HSQL but I have not necessarily got loads of memory to play with so
Derby seems to suit my needs best

And it has the advantage of not requiring a separate download.

 

[Arne Vajhøj]

Arne Vajhøj wrote on 25.01.2008 03:39:

And then there is H2 (www.h2database.com) which is maintained by the
initial developer of HSQLDB and seems to have more momentum than HSQL
currently.

HSQLDB must be downloaded double digit millions of times due to OOo.

Arne

 

[Roedy Green]

Is there a database I can use with my java application that does not
"install" on a user's PC?

Yes. see http://mindprod.com/jgloss/sqlvendors.html

At least one of them is just a a set of classes you bundle in your
jar.

Derby is part of Java. I'm not sure if it is always automatically
installed at clients.

Look for the terms "pure Java", "embeddable" to find candidates.

 

[Steve Sobol]

Yes. see http://mindprod.com/jgloss/sqlvendors.html

At least one of them is just a a set of classes you bundle in your
jar.

I think Derby and HSQL and Firebird all are. IIRC.

 

[Arne Vajhøj]

I think Derby and HSQL and Firebird all are. IIRC.

I believe it is true that Firebird can be embedded, but
Firebird is not written in Java, so would expect some
native parts to be required besides the jar.

Arne

 

[Thomas Kellerer]

Arne Vajhøj wrote on 26.01.2008 23:01:

HSQLDB must be downloaded double digit millions of times due to OOo.

I didn't mean the number of users. Actually I doubt that more than a small
fractioin of the OOo users are actually using the Base component as it is not
working really well.

I was more referring to effort put into development. The H2 developer seems to
be more active than the HSQLDB team.

Regards
Thomas

 

[Martin Gregorie]

I think Derby and HSQL and Firebird all are. IIRC.

Derby can either be embedded or run as a server and includes JDBC
implementations for both modes, so its more than just a set of classes.

IMO a database that can only work in embedded mode would be pretty
useless. Sure, embedded has its uses, e.g. as a periodically connected
application running in a PDA[1], but you normally want more that one
program to access a database. Using an embedded copy in each program
adds locking complexity and probably involves more of a performance hit
(as a result of lock collisions) than running a server.

[1] Derby's development history can be traced back to Cloudscape, which
was written specifically as a small footprint Java RDBMS for supporting
periodically connected applications. The idea was that a salesman or
support engineer would have a copy in a PDA that he could use to record
sales/deals/repairs etc. in the DB as they happened. Next time he was in
the office he'd connect the PDA to the office LAN and Cloudscape would
then sync automatically to the master database, uploading transaction
details and downloading any changes (e.g. prices).

Cloudscape was written by Californian startup, bought by Informix,
acquired by IBM when it bought Informix and renamed as Derby when IBM
donated it to the Apache organization.

 

[David Segall]

Derby can either be embedded or run as a server and includes JDBC
implementations for both modes, so its more than just a set of classes.

IMO a database that can only work in embedded mode would be pretty
useless. Sure, embedded has its uses, e.g. as a periodically connected
application running in a PDA[1], but you normally want more that one
program to access a database. Using an embedded copy in each program
adds locking complexity and probably involves more of a performance hit
(as a result of lock collisions) than running a server.

This implies that you must choose between embedded and client-server
mode to use Derby. This not necessary because Derby can be run as an
"embedded server". See
<http://db.apache.org/derby/papers/DerbyTut/ns_intro.html#Embedded+Server>
David Van Couvering provides some more details here
<http://davidvancouvering.blogspot.com/2007/08/java-db-its-both-embedded-and-server.html>.
This facility is worth emphasising. Even if an application will
eventually be run only using an embedded database being able to
examine the database while executing a program is an invaluable tool
during testing.

 

[Thomas Kellerer]

David Segall, 28.01.2008 13:04:

This implies that you must choose between embedded and client-server
mode to use Derby.

> This not necessary because Derby can be run as an "embedded server".

This is true for all three (Java based) "major contenders" (Derby, HSQL
and H2)

Thomas

 

[Martin Gregorie]

This implies that you must choose between embedded and client-server
mode to use Derby. This not necessary because Derby can be run as an
"embedded server".
>

I wasn't as clear as I could have been. What I wanted to point out is
that, as Derby can be run as a server "out of the box", it must be more
than simply a class library, i.e. it must also include class(es) that
can listen for and handle connections as well as providing a static void
main() method.

I've not used it yet (its next on the list to play with after Postgres)
but I'm aware that you can build a special purpose application +
database server that can also accept connections from a standard
database SQL clients or other applications.

I've known about its existence since its first appearance as Cloudscape,
so I then got a bit carried away with summarizing its history. I hope
that wasn't too much of a bore.

 

[Christian]

And it has the advantage of not requiring a separate download.

Why not?

Derby seems to be not included in most Java installations.
When I installed Java the last time there was an option for derby.
Default for derby is to be not installed.. So I assume thats what most
users will have.
Also I think I read on Ubuntu/Linux derby is a seperate package, so also
not mandatory.

Derby seems to be a good choice for testing stuff but it seems not to be
software that you can rely on being on the users machine.

Christian

 

[Lew]

Why not?

Because it is included with JDK 6 distributions.

Default for derby [sic] is to be not installed.. So I assume thats what most users will have.

I wasn't referring to users' downloads, but to yours. This is the same issue
for any database engine - you have to download it and somehow get it into your
users' hands. The advantage of Derby is that it comes with JDK 6 when you
download it, so it does not require a separate download /for you/.