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.
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 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.
as I said from the beginning.
