dbi-problems_with_sql_incompatibilities

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



To: ilya.sterin@pobox.com
From: Tim Bunce <Tim.Bunce@pobox.com>
Subject: Re: Postgres w/DBI
Date: Mon, 15 Oct 2001 09:51:45 +0100

On Sun, Oct 14, 2001 at 10:48:34PM -0400, Ilya Sterin wrote:
> >
> > DBI may be independent, but the fact that it does nothing with the SQL
> > that is sent to the database and the fact that SQL varies from vendor to
> > vendor means that there are database compatibility issues in SQL that
> > are not and should not be handled by DBI but must be handled by a layer
> > on top of DBI.
> >
> > I tire of stating this and I wonder why people want to gloss over this
> > glaringly obvious fact: SQL varies from vendor to vendor.

Very true.

I suspect that most people gloss over it simply because it's not
relevent to them. Relatively few people really have to face porting
non-trivial applications between databases.

> Definitelly does, but if you stick to the SQL standard than you should have
> no problems as most major db vendors implement the standard and if they
> don't than maybe you should reconsider.  Yes there are variances, but I
> would argue that in 90% of the applications the different implementations
> would not cause a problem.

I think you're being a little optimistic. Any use of functions,
date/time types, and non-trivial joins is very likely to take you
into non-portable syntax.

In the longer term the DBI will be getting some SQL rewriting
functionality based on ODBC escape sequences.

Right now I'd recommend DBIx::AnyDBD (or take a look at one of the
bigger 'frameworks' like RecordSet, Tangram, Albazoo, etc., if you
like that kind of thing).

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu