Need Relational Database Capabilties in Java

[JAF]

We are looking at converting some legacy apps o Java. The apps were
originally in a relational database software program. we want to keep
the data structures if possible.

Is there a way to do this?

We don't mind converting the structures int a new data container or
file system. However we would like to keep the same fields, records,
tables, etc.

Is there anyway to do this? And what would be the Java tools,
software, etc, that we would need?

Thanks
Best regards,

JAF
http://www.bscinc.net
http://www.affordablefloridainsurance.com
http://www.discountdrivingschool.com

 

[Robert Klemme]

We are looking at converting some legacy apps o Java. The apps were
originally in a relational database software program. we want to keep
the data structures if possible.

Do you mean data *and* logic were in the DB (i.e. stored procedures)?
Or do you mean to say only data is in the DB?

Is there a way to do this?

We don't mind converting the structures int a new data container or
file system. However we would like to keep the same fields, records,
tables, etc.

Is there anyway to do this? And what would be the Java tools,
software, etc, that we would need?

You can access a relational DB from Java via JDBC (and other tools that
do more abstraction, like object relational mapping tools such as
Hibernate).

And with some DB products you can also implement logic inside the DB in
Java (Oracle for example).

Kind regards

robert

 

[TechBookReport]

We are looking at converting some legacy apps o Java. The apps were
originally in a relational database software program. we want to keep
the data structures if possible.

Is there a way to do this?

We don't mind converting the structures int a new data container or
file system. However we would like to keep the same fields, records,
tables, etc.

Is there anyway to do this? And what would be the Java tools,
software, etc, that we would need?

Thanks
Best regards,

JAF
http://www.bscinc.net
http://www.affordablefloridainsurance.com
http://www.discountdrivingschool.com

Have you looked at using something like Apache Derby to integrate into
your Java application? There's a review of it here:
http://www.techbookreport.com/tbr0275.html

More details at the Apache Derby page: http://db.apache.org/derby/

HTH

 

[Thomas Hawtin]

We are looking at converting some legacy apps o Java. The apps were
originally in a relational database software program. we want to keep
the data structures if possible.

Is there a way to do this?

We don't mind converting the structures int a new data container or
file system. However we would like to keep the same fields, records,
tables, etc.

If you want a relational database within the Java process, there is
Derby. It's under the Apache license, so no worries about your own
intellectual property. Originally it was a commercial product called
Cloudscape written in the late nineties, then bought by Informix, who
were themselves bought by IBM. So it's not just some cobbled-together
half-implemented junk.

Then you may well want some form of Object Relational Mapping (ORM)
tool. Hibernate has been the traditional choice. The persistence part of
EJB3 is the knew kid on the block (not to be confused with bad old EJB).
You may also here of JDO, which just wont die.

Tom Hawtin

 

[bugbear]

Have you looked at using something like Apache Derby to integrate into
your Java application? There's a review of it here:
http://www.techbookreport.com/tbr0275.html

More details at the Apache Derby page: http://db.apache.org/derby/

At the risk of inducing topic drift what are the pros
and cons (in the context of your choice ;-) with hsqldb?

http://www.hsqldb.org/

We use hsqldb, because in its ram resident
incarnation we can create a schema, populate
it with a small amount of test data, run a test,
and demolish everything in milliseconds, which is
just F**kin' superb for unit testing.

In this way unit tests are genuinely independent,
whereas when testing against "real" DB's one failed
test can cause enough corruption/damage
to make other tests fail - the tests aren't independent.

BugBear

 

[TechBookReport]

At the risk of inducing topic drift what are the pros
and cons (in the context of your choice ;-) with hsqldb?

http://www.hsqldb.org/

We use hsqldb, because in its ram resident
incarnation we can create a schema, populate
it with a small amount of test data, run a test,
and demolish everything in milliseconds, which is
just F**kin' superb for unit testing.

In this way unit tests are genuinely independent,
whereas when testing against "real" DB's one failed
test can cause enough corruption/damage
to make other tests fail - the tests aren't independent.

BugBear

Not tried HSQLDB, but on paper at least the functionality is fairly
similar to Derby. I did see some benchmarks recently that did put HSQLDB
ahead in terms of speed, so perhaps next time the need comes up I'll
give it a go.

 

[Thomas Hawtin]

Not tried HSQLDB, but on paper at least the functionality is fairly
similar to Derby. I did see some benchmarks recently that did put HSQLDB
ahead in terms of speed, so perhaps next time the need comes up I'll
give it a go.

There were some benchmarks that made HSQL appear very fast. They just
used the defaults. HSQL defaults to in memory storage, so it is in no
way comparing like with like. Sometime ago I had a brief look at the
HSQL implementation. All commands ran under "synchronized (database)".
That is just mickey mouse.

I believe Derby has an option for 'transient' databases that don't sync
to non-volatile storage. That could make things much faster. It looks as
if an in-memory database feature is going to be added soon.

Tom Hawtin

 

[bugbear]

There were some benchmarks that made HSQL appear very fast. They just
used the defaults. HSQL defaults to in memory storage, so it is in no
way comparing like with like. Sometime ago I had a brief look at the
HSQL implementation. All commands ran under "synchronized (database)".
That is just mickey mouse.

For a lot of our unit testing HSQLDB is a good
enough database (we normally have TINY amount
of test data), and it's very high boot/create schema
performance is a godsend.

For component level testing we work differently.

Horses for courses, no silver bullet etc.

BugBear

 

[JAF]

On Thu, 23 Nov 2006 14:06:49 +0100, Robert Klemme

snip

Do you mean data *and* logic were in the DB (i.e. stored procedures)?
Or do you mean to say only data is in the DB?

Our legacy system only stored data in the DB.

All procedures and processes were in he code. They were very
"modularized" though, and we could use them in input routines and
reports without any trouble.

The two biggest pluses I see to the relational model for DB, and
please comment on my ideas here for Java since I am new to Java, are
the data is easy to maintain and it is easy to train end users to
understand relational data and to do heir own reports. By maintain I
don't mean the day to day input but rather the data schema over time.
We have had several times when we needed to add serious new
functionality to the system, and by adding a few fields and a few new
reports, we were able to do it without any serious reprogramming of
the scheme or the code.

Can we do this in Java?
Best regards,

JAF
http://www.bscinc.net
http://www.affordablefloridainsurance.com
http://www.discountdrivingschool.com

 

[Robert Klemme]

On Thu, 23 Nov 2006 14:06:49 +0100, Robert Klemme

snip
Our legacy system only stored data in the DB.

All procedures and processes were in he code. They were very
"modularized" though, and we could use them in input routines and
reports without any trouble.

The two biggest pluses I see to the relational model for DB, and
please comment on my ideas here for Java since I am new to Java, are
the data is easy to maintain and it is easy to train end users to
understand relational data and to do heir own reports. By maintain I
don't mean the day to day input but rather the data schema over time.
We have had several times when we needed to add serious new
functionality to the system, and by adding a few fields and a few new
reports, we were able to do it without any serious reprogramming of
the scheme or the code.

Can we do this in Java?

You can execute any DML and DDL commands via JDBC.

robert

 

[Chris Uppal]

The two biggest pluses I see to the relational model for DB, and
please comment on my ideas here for Java since I am new to Java, are
the data is easy to maintain and it is easy to train end users to
understand relational data and to do heir own reports.

If you want to interact with the DBMS at the level of SQL queries, tables,
rows, and so on, then that is provided by JDBC.

There's a tendency in the Java world to /assume/ that anyone interacting with a
DBMS will want to use a Object-Relational mapping tool (such as Hibernate) to
handle the translation from the world of relational data into the world of
objects, but that assumption is not necessarily valid. The data can perfectly
well be represented (in Java) as objects from the relational domain (rows, etc)
rather than being automatically transcribed into objects from the target domain
(customers, etc). And if you are already happy working with those concepts,
then I don't (myself) see much benefit in changing.

-- chris

 

[Daniel Pitts]

There's a tendency in the Java world to /assume/ that anyone interacting with a
DBMS will want to use a Object-Relational mapping tool (such as Hibernate) to
handle the translation from the world of relational data into the world of
objects, but that assumption is not necessarily valid. The data can perfectly
well be represented (in Java) as objects from the relational domain (rows, etc)
rather than being automatically transcribed into objects from the target domain
(customers, etc). And if you are already happy working with those concepts,
then I don't (myself) see much benefit in changing.

-- chris

Actually, its a tendency of Object Oriented Programmers world to assume
that anyone interacting with data at all, regardless of its source.

Object Oriented Design allows you to have a rich domain model. The
domain model will know how to manipulate and present itself (to a
point), in such a way that it reduces complexity of code. If you are
moving to Java JUST to move to Java, then I suggest you reconsider. If
you are moving to Java so that you can become a (true) OO shop, then I
suggest you think of ways to utilize your data in a more OO fashion.

 

[Simon Brooke]

If you want to interact with the DBMS at the level of SQL queries,
tables, rows, and so on, then that is provided by JDBC.

There's a tendency in the Java world to /assume/ that anyone interacting
with a DBMS will want to use a Object-Relational mapping tool (such as
Hibernate) to handle the translation from the world of relational data
into the world of
objects, but that assumption is not necessarily valid. The data can
perfectly well be represented (in Java) as objects from the relational
domain (rows, etc) rather than being automatically transcribed into
objects from the target domain
(customers, etc). And if you are already happy working with those
concepts, then I don't (myself) see much benefit in changing.

Further to that, the various object-relational mapping frameworks are all
fairly heavyweight and add greatly to the complexity and computational
expense of your software. They are great sledgehammers, but if what you've
got is a nut they are cumbersome and dangerous.

 

[Simon Brooke]

Actually, its a tendency of Object Oriented Programmers world to assume
that anyone interacting with data at all, regardless of its source.

Parse error: no apparent main verb. Syntactic analysis terminated.