Re: Myth of the database independent applications (Was: Are you using PL/SQL)

On May 24, 2:39 pm, Mladen Gogala <mgogala.SPAM_ME...._at_verizon.net> wrote:
> On Wed, 23 May 2007 15:11:07 -0700, zigzagdna wrote:
> > In practice, you cannot make your application as database independent by
> > writing lots of stored procedures in PL/SQL.
>
> There is no such thing as a database independent application. There is no
> Nessie, there is no elixir of youth and there is no Humpty Dumpty. Never
> was, never will be.
> Databases have vastly different optimizers, locking strategies, connection
> management policies, vastly different ways of performing I/O and caching
> and vastly different implementations of transactional primitives. Some
> databases allow dirty reads, some do not. Some implement consistency
> through locking, some through multiversioning.
>
> The only way to create a figment of imagination called "database
> independent application is not to use databases at all. The truly
> database independent applications are vi editor, flex, bison and Perl.
>
> If you commit yourself to writing an application using databases, then
> you should know what underlying database will you use. The most important
> application design principle which is broken most of the time is that
> general business rules should be implemented in the database and not in
> the user interface. Also, rules which are local to an application module
> should be implemented in the UI. The best sign of breaking the rules are
> the expressions like ":VAR = 0" in the SQL. Conditions on variables should
> be checked in the UI.
>
> Unfortunately, this is precisely the thing frequently generated by one of
> the most popular tools "for writing database independent applications",
> namely Hibernate. Hibernate helps you create applications which will suck
> regardless of the underlying platform.
>
> --http://www.mladen-gogala.com

Most of the software projects I worked on there are three layers (some people call them tiers, tier does not mean separate servers): User Interface, Business/Application Logic and Database. User Interface simply does user interface, displays screens, gets data from the user. Database stores data, there may be some triggers, but database does not use any stored procedures. Business/ Application logic is where all the logic/algorthsm etc are implemented. Business logic calls database to get data and update/ insert/delete data. Thus database code is little. Using OO techniques, it is not all that difficult to write database classes in such as fashion that they are mostly database independent. Sure there will be some differences from one database to another, but differences are lot less than if one was writing stored procedures in database propritery language. Business logic can run on same server as database server then network time is reduced drastically. Middleware/ interprocess communication provides efficient ways to communicate from user interface to business logic and to distribure business logic into many processes/threads. Business logic can use JDBC to connection to databases if business logic language is Java.

I have worked so many projects using such architecture and performance has never been an issue. For many software vendors it is more important to be able to support many databases without writing lot of database specific code than reducing performance times by taking advantage every proprietery feature of a database. Received on Thu May 24 2007 - 17:43:17 CDT