Re: Call for an API standard for SQL statements

"Fredrik Bertilsson" <fredrik_bertilsson_at_passagen.se> wrote in message news: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.

But to save the work of having to pick the right constructor out yourself you add more work than you save by requiring your queries to be expressed in some ad-hoc OO framework.

> > > 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.

I don't think you got my point. The issue is that once you start abstracting out the details of queries, the application code becomes divorced from the actual SQL being executed, which quickly leads to bad performance. The app coder *must* be aware of the consequences of what he's doing in order to go a good job.

> > 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.

So you're working for an ISV, and delivering apps to multiple customers using multiple RDBMSs; that falls under the exclusion clause I put in. Custome business apps don't need DBMS independence, but ISV's apps do.

Marshall Received on Sat Oct 23 2004 - 20:16:22 CEST