Re: Call for an API standard for SQL statements

From: Marshall Spight <mspight_at_dnai.com>
Date: Fri, 22 Oct 2004 01:56:39 GMT
Message-ID: <rNZdd.284729$MQ5.92463_at_attbi_s52>


"Fredrik Bertilsson" <fredrik_bertilsson_at_passagen.se> wrote in message news:31f7e57d.0410210842.440aa8f2_at_posting.google.com...
> "Marshall Spight" <mspight_at_dnai.com> wrote:
> > > But the main purpose for having an object model is not to make the
> > > query building more compact. The purpose is the let the database
> > > framework have knowledge about how the query is constructed, which
> > > makes a lot of extra features in the framework possible.
> >
> > Such as?
>
> One feature I use is that I want custom datatypes. Lets say I have a
> table column for telephone numers. In the database it is just a
> VARCHAR, but in my application I handle this value as an instance of
> the class TelephoneNo. Immediately after reading my framework converts
> the string to an instance of TelephoneNo. To be able to do this I have
> associated this column with the class TelephoneNo in a configuration
> object. But when my framworks runs a query it need to know which
> columns that are involved, so the right datatype could be used.

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.

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

This kind of approach may work well for small projects, like 1-3 developers, but for a team of 20, it would be a disaster. There is no substitute for having your team learn how to use SQL.

> A third example is data-aware GUI components. Lets say we want to make
> a search panel which takes a query object, builds a GUI and let the
> user fill in the parameters. This is of course only possible if we
> have have a query object.

These are cool.

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

Marshall Received on Fri Oct 22 2004 - 03:56:39 CEST

Original text of this message