I read the article as well, but while I found the artcile itself to be good, I disagree with the DBIx concept. Writting DBI without SQL has to be the same feel as driving a Porsche with auto-transmission. I like SQL and enjoy having absolute control over every little detail, but then again, that's my bad. :)

It seems to be that DBIx is (yet another) layer between the application and the database. The concept seems to interesting at first, but once you stop and think of it, whats the point really? Getting you to do you're work faster? More portability? Those can be acheived by knowing your tools better and finding a least common denominator.

That's what I do with SQL (and HTML). I have the exact oposite setup that you do. I'm writing SQL for MySQL and porting it to Oracle later on. Finding the least commong denominator between the both isn't that hard. I just run a Find/Replace on varchar, enum, int, and fields of the sort and then go through manually and find whatever needs special attention. I find that to be more practical, safer, and it usually on takes an extra 15 minutes per database.

Just my usual R$0.02...

#!/home/bbq/bin/perl
# Trust no1!