On Nov 28, 2007 1:45 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 28 Nov 2007 11:48:23 +0100 "Chris Johnson" <cxjohnson@gmail.com> wrote:
Maybe there is an open-source tool which can validate standard SQL which could be used. Then our DB abstraction could require a verifiable standard SQL syntax which would then be translated (where necessary) into the MySQL, Oracle, Postgres, etc. equivalents. This might only be for CRUD operations (data manipulation statements) and not for DDL, for which we already have a reasonable API and which are much less standardized.
On the long run this doesn't give space for optimisations. People should write SQL with standards in mind and not MySQL in mind but the DB abstraction layer should leave a door open for optimisation. There should be a default path that doesn't impact on performances (including both mysql and pgsql code) that let module writers write custom code for a particular DB *if* they are willing to do so.
Well, actually I'm very much in favor of optimized SQL, because I'm very much in favor of optimized Drupal. I hate software bloat. So what I really think -- and this is a truly unpopular position -- is that most of the SQL should be written by "core" SQL coders, and the rest of us should be accessing data through object abstractions, i.e. get me a node, get me a user. Underneath is the highly optimized, shiney, sparkly, incredibly brilliant PHP and SQL code written by the 'database access guru core team'. Ok, I'll put the crack pipe down now. My goal with the above suggestion was just to make it easier for people to write the standard SQL to MySQL || PGSQL || MS SQL || Oracle abstraction-layer translation stuff by helping authors avoid difficult to translate non-standard-isms. If developers can avoid creating modules which depend on unique special extension X in MySQL or special extension Y in Postgres (unless they really meant to), then we'd be better off in our question to support more than one database. I suppose I have not made things much clearer. For some reason, I'm plagued with complicated phraseology today. :-/