-----Original Message----- From: Terrence Brannon To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: 12/31/69 5:17 PM Subject: Re: Postgres w/DBI
On Sunday, October 14, 2001, at 07:48 PM, Ilya Sterin wrote: >> I tire of stating this and I wonder why people want to gloss over this >> glaringly obvious fact: SQL varies from vendor to vendor. > > 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. > >1 - I was reading a book on SQL (I forgot which one), but it went >through introductory SQL for both Access and Oracle. And I do remember >that the syntax for outer joins was vastly different between the two. >But I can state with confidence that database applications written with >Recordset run without changes on both databases... this is a complete >impossibility with vanilla DBI. True, but I would rather not discuss Access SQL (Jet SQL). Don't remember the last time MS willingly followed any standard. >2- It is a stated fact in the DBI docs : > Calling stored procedures is currently > not defined by the DBI. Some drivers, such as > DBD::Oracle, support it in non-portable ways. See > driver documentation for more details. That's true, but I don't believe we were talking about stored procedures? >That being said, moving from mysql to postgresql and leveraging the >features of postgres would entail some usage of stored procs... to get >server side speed instead of un-necessary client-server interaction. >Thus, if you want to limit your Postgresql usage to what MySQL is >capable of, then fine. But if you plan to make use of Postgresql in an >optimal fashion or Oracle or anything more scalable and feature-packed, >then you will have to > 1 - focus on one database for the SQL code > 2 - use DBIx::AnyDBD as I mentioned from the beginning > 3 - use available SQL abstraction layers. You are correct and I am not arguing against the above, but rather am trying to state that if carefully coding with portability in mind, most RDBMS (major) follow the defined standard SQL, but there are many enhanced options as well as differences in implementation defined stuff. I've ran into this problem before with Oracle and MySQL, and carefully rethinking the SQL in cases where the DB specific functionality was not required, I was able to bypass the yet another layer. Of course there extra layers are critical for many applications, but I was just thinking from my experience:-) Ilya >as I said from the beginning.
