multiple/any Database-Module with jdbc

Thread view:

gert - 12 Mar 2007 20:49 GMT

Hey,

i want to use in my application any database, example hsql, mysql,
oracle, etc. . For the specified database-connection i think to write
modules. Have anybody samples or tricks for developing the function/
modules?
How registered itself the module on a application?

Thanks.

gp

Reply to this Message

ck - 12 Mar 2007 20:58 GMT

> Hey,
>
[quoted text clipped - 7 lines]
>
> gp

Are you aware about hibernate? http://www.hibernate.org

--
Ck

Reply to this Message

ck - 12 Mar 2007 22:12 GMT

> Hey,
>
[quoted text clipped - 7 lines]
>
> gp

Are you aware about hibernate? http://www.hibernate.org

--
Ck

Reply to this Message

Lew - 13 Mar 2007 00:20 GMT

"gert" <gert.pin...@web.de> wrote:

>> i want to use in my application any database, example hsql, mysql,
>> oracle, etc. . For the specified database-connection i think to write
>> modules. Have anybody samples or tricks for developing the function/
>> modules?
>> How registered itself the module on a application?

Use JDBC, at least. (Frameworks that sit atop JDBC are a trivial extension of
the idea.)

Your code that uses JDBC will not change with different databases.

Put the database Driver class name and connection strings in a property file
and load the properties at program startup.

For a JDBC driver class name stored in a String variable "driver" you
"register ... the module" by

Class.forName( driver );

which loads the driver class and registers it with the DriverManager.

Check out the tutorials on JDBC.

-- Lew

Reply to this Message

Arne Vajhøj - 13 Mar 2007 02:20 GMT

> "gert" <gert.pin...@web.de> wrote:
>>> i want to use in my application any database, example hsql, mysql,
[quoted text clipped - 5 lines]
> Use JDBC, at least. (Frameworks that sit atop JDBC are a trivial
> extension of the idea.)

It is rather difficult to write database code in Java that does not
use JDBC.

:-)

> Your code that uses JDBC will not change with different databases.

That is the goal. It is even possible for simple database
usage. But for more advanced database usages it often becomes
very difficult.

As soon as you need something non standard SQL then it
becomes tricky.

Arne

Reply to this Message

gert - 13 Mar 2007 07:42 GMT

Hello Lew,

> "gert" <gert.pin...@web.de> wrote:
> >> i want to use in my application any database, example hsql, mysql,
[quoted text clipped - 7 lines]
>
> Your code that uses JDBC will not change with different databases.

yest i use it early.

> Put the database Driver class name and connection strings in a property file
> and load the properties at program startup.
>
> For a JDBC driver class name stored in a String variable "driver" you
> "register ... the module" by
> Class.forName( driver );

ok, i have it so. I meant how does load the program the properties/
module at startup? How make it neatbeans to example? Read/scan the
program a directory where the modules there are?

i'm on the right way. :)

regards

gp

Reply to this Message

Lew - 13 Mar 2007 14:20 GMT

> ok, i have it so. I meant how does load the program the properties/
> module at startup? How make it neatbeans to example? Read/scan the
> program a directory where the modules there are?

Use Properties files.

During initialization of the module load the JDBC driver using the property
for the DB driver that you define in your Properties file. Connect to the
database using properties defined in your Properties.

You will find what you need to know in the API docs for java.util.Properties.

-- Lew

Reply to this Message

ck - 13 Mar 2007 19:19 GMT

> > ok, i have it so. I meant how does load the program the properties/
> > module at startup? How make it neatbeans to example? Read/scan the
[quoted text clipped - 9 lines]
>
> -- Lew

In case you are planning to use Properties, you would need to put the
database queries and DML as well in the Properties file. In some
situations the DML and queries can be Database specific. Hence if they
are hard coded in the class you would need to do something about it.

--
Ck
http://www.gfour.net

Reply to this Message

Lew - 14 Mar 2007 06:01 GMT

> In case you are planning to use Properties, you would need to put the
> database queries and DML as well in the Properties file. In some
> situations the DML and queries can be Database specific. Hence if they
> are hard coded in the class you would need to do something about it.

Need to? No. Want to? Maybe, but I doubt it.

How many projects have you ever been on that changed DMBSes?

Why in the world would you use DBMS-specific constructs if you are ever
planning to change DBMSes? Use vanilla SQL and put the tricky stuff in the
Java code.

Consider if you had such a properties file. It could be massive, incredibly
hard to debug, and just as difficult to change as code if you did switch back
ends. The code that used those SQL statements would be segregated from the
logic that it implements and thus much harder to debug and maintain.

If the code is in well-designed DAO-layer classes, then the effort of changing
the SQL is the same if you change back ends, but maintenance and debugging for
the much more usual case of not changing DMBSes is much, much easier. Locality
of reference applies to the mind, not just memory chips and caches.

Keep the SQL with the Java code that uses it, not in a properties file.

-- Lew

Reply to this Message

ck - 14 Mar 2007 09:27 GMT

> > In case you are planning to use Properties, you would need to put the
> > database queries and DML as well in the Properties file. In some
[quoted text clipped - 4 lines]
>
> How many projects have you ever been on that changed DMBSes?

If that was the situation then this question would have not existed in
the first place.

> Why in the world would you use DBMS-specific constructs if you are ever
> planning to change DBMSes? Use vanilla SQL and put the tricky stuff in the
> Java code.

> [Clipped]

May be using properties file is a bad idea but what I wanted to convey
was that -

There are lot of DB specific features, which developer might use to
develop the application(initially), later when you have to migrate to
someother DB its a problem. For that matter Databases don't follow any
standard for DML or Queries, in my opinion Oracle is a leader at
breaking the standards set.

Ck
http://www.gfour.net

Reply to this Message

Lew - 14 Mar 2007 14:25 GMT

> in my opinion Oracle is a leader at breaking the standards set.

MySQL and MS Access have Oracle way beat.

-- Lew

Reply to this Message

Arne Vajhøj - 15 Mar 2007 00:48 GMT

>> In case you are planning to use Properties, you would need to put the
>> database queries and DML as well in the Properties file. In some
[quoted text clipped - 4 lines]
>
> How many projects have you ever been on that changed DMBSes?

Ever head about "products" that needs to support many databases.

> Why in the world would you use DBMS-specific constructs if you are ever
> planning to change DBMSes? Use vanilla SQL and put the tricky stuff in
> the Java code.

Sometimes you need database specific features.

Try think about why most persistence frameworks require
you to specific the SQL dialect.

> Consider if you had such a properties file. It could be massive,
> incredibly hard to debug, and just as difficult to change as code if you
> did switch back ends. The code that used those SQL statements would be
> segregated from the logic that it implements and thus much harder to
> debug and maintain.

You may be right.

But non the less the use of putting critical information in
config files is rather widely used in Java - from EJB's to
Hibernate to Spring.

Arne

Reply to this Message

multiple/any Database-Module with jdbc

Free Magazines