Re: New PDO-based DBAL/ORM for PEAR2

Hi, till wrote:

Funny that I managed to port my CMS from MySQL to PostgreSQL in 2 hours (mostly fixing reliance on non deterministic group by's) and to SQLite in 3 hours (1 hour was used to add a feature to handle the fact the SQLite by default qualifies joined columns with the table name unless aliased) as it was based on MDB2. I should also mention that the installation tools based on MDB2_Schema needed no alterations. I also did not feel like I was artificially limiting myself. For example one thing that did require custom code was the internal search, which was based on MySQL's FULLTEXT indexes. But that was a minimal amount of work and a tiny addition to the code. Just to set the record straight.

Porting something *from* MySQL isn't an impressive feat, due to its limitations. Now if your abstraction layer allowed porting an application written and optimised for Oracle (or PostgreSQL) *to* MySQL in 2 hours, that'll be something to be proud of. Going for "database abstraction" is IMO an extremely bad thing, since it encourages coding for the Lowest Common Denominator (MySQL / SQLite). Of course having an unified API for fetching the rows helps a bit, but the underlying logic should be written and optimised for each DBMS, not written for MySQL and ported everywhere else as an afterthought. And that means hand-tuned separate schemas, not a dumbed-down schema meta-language.

Correct me if I am wrong, but you could still write your *whatever-specific* code and fire it up through query/exec and deal with it yourself. I mean, I like MDB2 not because my apps are constantly deployed with different backends (even though I have clients who use the same app but run MSSQL, Postgre, SQLite and MySQL) but the beauty lies within all the shortcuts.

Yes, that's what I mean: DBALs are good while you are using them to abstract the client API and add shortcuts for getting the whole resultset, the whole column, etc. When you start using them for abstracting actual SQL 1) You have to learn a new language 2) That language is a lot less powerful than DB-specific SQL What was the database you application was originally written for? I'd bet it was neither MS SQL nor Postgres...