Re: Call for an API standard for SQL statements

"Fredrik Bertilsson" <fredrik_bertilsson_at_passagen.se> wrote in message news:31f7e57d.0410210842.440aa8f2_at_posting.google.com...

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

Do you really need custom datatypes, or just custom domains?

Does your DBMS support CREATE DOMAIN? If not, why not?

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

Gee, I never had any trouble doing this with the Datatrieve report writer, way back in 1982!

Have later report writers become less competent?

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

I'm not sure about this.

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

Why wouldn't it be easier to translate back and forth between standard SQL and the vendor's dialect SQL?

>
> Fredrik Bertilsson
> http://butler.sourceforge.net
Received on Thu Oct 21 2004 - 19:51:27 CEST