On Wed, 1 Aug 2001, kyle dawkins wrote:
kd> Not sure if you're aware of it, but that argument is pretty old.
kd> We're onto a much more interesting, new argument now. :-)
All old arguments eventually becomes new again, once in a while... :-)
kd> Seriously though, you're right, MySQL is not a "real" RDBMS. No
kd> transactions, no foreign key constraints, no stored procedures.
kd> It is, however, free, and in use in a lot of places. And
kd> interestingly enough, in a way that makes the current argument
kd> even MORE important; writing SQL into your code (as per the
kd> current thread of discussion) will make it exponentially more
kd> difficult for you to move to a "real" RDBMS as Henrik urges you
kd> to. If you abstract DB access into a middleware layer, you will
kd> have a much, much easier time. By placing SQL into your
kd> application code, you are removing the flexibility of changing
kd> your persistence mechanism at a later date. And believe it or
kd> not, that's not as uncommon as you might think.
Or you can make sure you do not use any of those features and write pure
SQL92. I have managed so far to write one SQL statement (no if's) for what
I want to do, and it works with PostgreSQL, Oracle, (those two I use) and
even with MySQL and others. You have to be careful and have a SQL92
definition handy, and it doesn't take much extra time. Then you get easy
portability to other DBMS with DBI/DBD. (And yes, I do seperate code and
content, Perl and HTML, with the excellent Template Toolkit.)
There are times when abstracting your SQL has a use, and times when it is
overkill. If you can't write clean SQL92 (or what you are aiming at)
then you do need to abstract yourself even more than DBI already does. I
am though very anti the use of DBMS-specific SQL.
Regards, Henrik
--
Henrik Edlund <[EMAIL PROTECTED]>
http://www.edlund.org/
"You're young, you're drunk, you're in bed, you have knives; shit
happens." -- Angelina Jolie
