Posted by Steve on 11/12/07 02:15

"AnrDaemon" <anrdaemon@freemail.ru> wrote in message
news:763926623.20071112003911@freemail.ru...
> Greetings, Jerry Stuckle.
> In reply to Your message dated Sunday, November 11, 2007, 17:05:47,
>
>> Why complicate things by putting SQL statements in a different file
>> where you can't see them?
>
> It may be not that clear for You, but I actually support one project
> runned on 2 different databases at the same time. (MySQL and MS SQL
> server)
> And that schema was found better in all cases.
>
>> And why go to all that hassle when you can
>> use ANSI-compliant SQL and have it work on virtually every database
>> (except MS Access)? Complicates things unnecessarily, IMHO.
>
> Well, can You translate cross-databse reference like [db1].[dbo].[table1]
> ?

actually, yes! even when working on the same db platform, it is a better
practice to create a view or other alias for the cross reference *in the
db*...not *in the code*. the db itself should handle that level of
minutia...after all, it's the *data layer*. code resides on top of that.

if you feel that your code should not only handle the processing of data but
the management of db relationships, particularly its sources, you will
forever entagle two layers that should be more losely coupled. the result
will be an explosion of re-writing any time you change your back-end
configuration.

by the same reasoning as having to specially denote column names that are
also reserved words, forcing in-line code to denote special
cross-referencing that are also db-specific and NOT ANSI compliant, you've
shot yourself in the foot.

luckily, this is a php context and changes to accomodate such 'mistakes' are
at least localized to source code distributed (usually) on one
computer...the web server. were this compiled sourced distributed as a
client application, you'd quickly see the wisdom in keeping the iso-seven
layers as seperated as possible.

[Back to original message]