Re: Call for an API standard for SQL statements

From: Fredrik Bertilsson <fredrik_bertilsson_at_passagen.se>
Date: 22 Oct 2004 08:27:33 -0700
Message-ID: <31f7e57d.0410220727.458b3dc0_at_posting.google.com>


"Marshall Spight" <mspight_at_dnai.com> wrote:
> Yeah, I could see this being useful on the app side. But I don't
> see why you need a framework for it, particularly. You just have
> a TelephoneNumber constructor that takes the varchar.
The job the framwork do it to find the correct datatype for the column and call the TelephoneNumber constructor. Otherwise you have to do the transformation explicit after every query execution.

> > A second extremly useful feature is converting a two-dimensional query
> > result into a hierachical view. Lets say that we have a query joinin
> > the tables "Order" and "OrderDetail". My framework returns a list of
> > "Order" records, but calling the method "getRelatedRecords" on such
> > instance, will return a list of "OrderDetail" records. This feature is
> > only possible if the framework has knowledge about wich tables are
> > participating in the query.
>
> Yeah, I know *all about* this style of programming, and it leads
> to disaster. You end up with commands that generate *hundreds*
> of queries for a request that could be done in 3, but by then
> it's too baked in to you architecture to extract yourself from it.

I am not talkning about replacing relational queries with network navigation. But network navigation can be a nice complement.

> > Finally, maybe the most important feature of all. Database vendor
> > indepence. Unfortunately the most popular databases have small syntax
> > differences in their SQL language. Using object representation of SQL
> > statements is a very easy way to build the correct SQL string for the
> > target database.
>
> Everyone talks about this feature, but how often does a real business app
> change databases? Pretty much never. This feature would be useful,
> though, for a shrinkwrap app that was written to work with any
> of a number of different RDBMSs.

I am working with a large enterprise system that we recently have converted from Informix to Oracle and later we will also have to support SQL Server. In my field of business, HR, you need to support all the major database vendors if you want to sell anything. The last years the database market have changed rather quickly and the customers don't want to be tied to old, expensive databases.

Fredrik Bertilsson
http://butler.sourceforge.net Received on Fri Oct 22 2004 - 17:27:33 CEST

Original text of this message