Re: acceptable way to program

fishfry <BLOCKSPAMfishfry_at_your-mailbox.com> wrote:
> Is this really true? I'm an experienced database programmer learning the
> Java/OO way of doing things and I'm puzzled that people use Hibernate
> and similar tools to define objects, with the database serving as just a
> passive serialization mechanism with no thought to database theory. How
> can this possibly work in real life? Also I've been told that stored
> procedures are not supported by Hibernate, is that true? How can it be
> that 20 years of relational theory seems to be getting thrown out
> overnight? Or am I just misinformed?

There is undoubtedly some bad database programming being done by Java programmers (and by C programmers, and especially by VB programmers, etc.). Nevertheless, the use of Hibernate doesn't represent poor database programming practice. What you should look for instead is ay of the following indicators of poor use of Hibernate:

• Use of Hibernate when it's a poor idea. If a task is inherently suited to a tabular view of data, then Hibernate isn't necessarily the best tool. Also, if an application looks at data in a lot of different combinations and does a lot of selecting of specific columns and joining of tables (particularly in ways that aren't easily predicted at development time), then Hibernate is obviously not the best way to do this. These are tasks which are best accomplished in a relational model. Use of Hibernate to write an application that naturally fits into the relational model is a bad idea.
• Use of Hibernate's tool to convert existing objects to an autogenerated database schema, if that schema might be used by a separate application. That derives the data model from the functional model of that data in a specific application, and that is a bad idea for data that will be shared between multiple applications.

It should be mentioned here that I am referring to data that might be used by multiple applications *right now* under current requirements. If the data might be used three years from now by a separate application and the current application isn't that awfully proliferant, I wouldn't worry about it. It only takes a weekend or so to write a tool that moves data from the old database to a new database schema if there's no live application.

As for stored procedures, it is true that current production releases of Hibernate cannot use stored procedures for the simple CRUD tasks that are implemented by Hibernate. You can, however, call stored procedures in the database just fine. Version 3 can even use stored procedures for CRUD operations, and there's a beta available for version 3. Nevertheless, it would be a royal pain to write stored procedures for every little thing like that. Data validity can be better checked in the database with constraints and triggers without interfering with the application interface. Stored procedures (at least, though exposed to applications) are best reserved for domain-specific logic, and don't need Hibernate to be called anyway.

Stored procedures are, of course, not any part of relational theory at all, so it's silly to complain that relational theory is being thrown out. Use of Hibernate in no way contradicts relational theory.

-- 
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation