Re: [gtk-list] Re: GNOME Database kit ODBC interface

[Christopher Blizzard <blizzard appliedtheory com>]

O'CONNOR, Steve wrote:
> 
> STOP IT NOW ...
> 
> ODBC is bad, bad, bad ... it is poison, dont use it.
> 

Why?

> All you need for a GNOME generic database interface is the following
> collection of functions -
> 
> - result_set* execSQL (char *str);       where str is an SQL statement
> to execute. Returns a result set *
> - char* getValue (result_set *, int row, int column);
> 
> The result set structure should contain information such as :
> for a 'select' type of result -
> - A status saying whether the call failed or succeeded
> - Number of rows in the result set
> - Meta information on the types of data in the columns of the result set
> for an update type of result -
> - A status saying whether the call failed or succeeded
> - Number of rows updated
> 

Can I bind statement parameters to statements?  How about preparing
statements? Some databases can take advantage of them.  Transactions
anyone?

What about listing the available database sources and the possible
datatypes in the database?

> This is based on the PostgreSQL C lib functions, but writing wrappers to
> things like Oracle using OCI routines, or Informix, etc is very trivial
> and very high-performance. Writing an ODBC driver from scratch is almost
> impossible in comparison, and at the end of the day you have a very high
> level interface that slows down your database, and removes all control
> from the programmer. If you want to get a feel for ODBC before writing
> any code, try putting on some Ski Gloves and tieing your shoelaces a few
> times.
>
> ODBC is another microsoft 'innovation' - lets say you want to write an
> ODBC driver for mySQL .. first port of call would be to go to the M$
> website and search the 'Knowledge Base' for the specs for the ODBC
> interface. Good luck ...   After about a week of painful searching you
> will discover that ODBC is not a 'spec' like you would expect to find,
> but rather a 'collection of concepts and technologies' which are not
> documented in any detail anywhere that I could find.
> 

"The ODBC API is based on the CLI specifications from X/Open and
ISO/IEC.  ODBC fully implements both of these specifications -- earlier
versions of ODBC were based on preliminary versions of these
specifications but did not fully implement them..."

Blame X/Open and ISO, not Microsoft for this one.  They went with an
established API when building ODBC.

> The best thing that I can suggest that you do is to write some useful
> applet that talks to a known database. Use every trick that the database
> library allows you to use. Now, port the applet to a second database.
> Repeat the port for a third database. Now, look at which bits are
> common, which bits need to be wrapperized, and do it in such a way that
> you can still optimize your applet to make use of special tricks offered
> by certain databases.
> 

And you're back to where we were before things like ODBC came about.  If
you want to use the specific capabilities of a database, write to their
native API in your favorite language.  Most applications don't need that
level of detail and ODBC suites them just fine.  ODBC exists, it works,
it's not terribly ugly and is well documented in quite a few books. 
And, bonus, there's already an infastructure of drivers and a GPL'ed
driver manager.

--Chris

ps. Why is this on the gtk list?

-- 

------------
Christopher Blizzard
http://odin.appliedtheory.com/
------------