It's just a fancy way of sending raw SQL statements to the database.

As long as different databases use different syntax for common functions, such as say limiting the maximum number of rows to be returned in a query, then each application must be coded and tested against the database it will be used with.

Give us a framework that lifts the application away from the database and lets the programmer deal with objects and not queries and rows or each application that strives to be portable will be forced to create such a framework for itself.

And this same bug-ridden busywork will be repeated over and over again.

I find the suggestion that you would develop against one db and deploy to another to be bizarre at the best. You'd have to be insane to do it deliberately.

It might be less stupid if all you're doing is CRUD operations, but if that's all you're doing, then why are you spending money on a high-end database product like Oracle?

The Zend Framework has libraries that allow you to code your SQL instead of typing in the raw SQL.

http://framework.zend.org/manual/en/zend.db.select.html

I haven't actually used it much yet but it certainly looks interesting.

In the past 7 years, I've seen dozens of these cross-plaform-frameworks come and go... but never used 1 of them, why?

They're useless and while some applications do need to run on different platforms (mostly open source projects) the rest of the real world tends to code systems targetted for 1 plaform, as its cheapers, more maintainable and much more robust.

If developers of PDO really want to product something useful, they need to concentrate on a decent ORM framework!

I've been using PDO for a good while now, and whilst it semi-abstracts certain things, I wouldn't use it in the scenario mentioned.

I mostly use it because of things like query preparation (which is implemented quite nicely)

nice little article. the pain and suffering involved when moving a working system from a MySQL testbed to a PostgresQL production service isnt nice and really unneccessary - thinking to PERL its a pretty transparent move due to same/very similar calls.

still, this is like ZENDs offering and still wont handle those real

calls made to the DB.

It seems like the developers of PDO have done a lot of work for no real gain, apart from allowing developers to use pretty PHP classes instead of the mysql_* commands.

Agree with the comments above, if they really wanted it to work they should have developed some abstracting classes to allow true interoperability with different SQL syntaxes.

Unless I'm mising something, yeah on the surface it looks nice, but doesn't really do anything useful... ooh, kinda like Paris really!!

cakephp?

Never mind this half-baked stuff. Wait 'till you see my framework framework, which allows you to develop in a way that's portable across all the many frameworks. It's going to be truly revolutionary.

I'm using it now, to build my price comparison site comparison site.

PDO is not a total abstraction layer, and improvements in PDO are being made.

Please refer

http://wiki.php.net/rfc/pdov1

For goodness sake people. Learn SQL, then find one or two decent databases and stick with them. If you want to save a few quid, use SQLite to prototype and demo to the punter, and then upgrade it to PostgreSQL if you really need to. The upgrade is fairly simple.

If you really must use a framework have a look at Django, at least it is pretty consistent, scales OK, and uses Python, so you will be spared the pain that is PHP...

The author falsely stated that PDO's greatest feature is code portability. There is only partial portability - on API side, not on SQL side.

Though, having SQL incompatibilities with PDO is still far better than having SQL _and_ API issues with pg_*, mysql_, oracle_*, etc functions. Just a drop of common sense is required to write fairly portable SQL statements.

The biggest advantages of PDO are in my opinion 1) prepared statements and 2) safe input 3) multiple connections.

I agree that PDO is a waste of time, but who in their right mind uses php and mysql with windows? linux is where its at, no?

Anyway, why abstract out all the databases - why not just pick one like mysql and stick to it? Then you can get the most from that database platform.

>> I find the suggestion that you would develop against one db and

>> deploy to another to be bizarre at the best. You'd have to be

>> insane to do it deliberately.

>>

>> It might be less stupid if all you're doing is CRUD operations,

>> but if that's all you're doing, then why are you spending money >> on a high-end database product like Oracle?

Nicely put. I can see why sometimes it is necessary to make your application support multiple platforms, even if that limits you to the lowest common denominator. However portability requires that you develop (to a greater or less degree) for all the platforms you support. I don't see how you can just develop for one and expect the others to just work; no matter how good your abstraction layer is.

The database isn't going to stick with you.

Yes, most SQL queries written for previous versions of MySQL will run on version 5, but the changes in the API ensure that your performance is going to really suck unless you rewrite the queries to the latest version.

And when you do rewrite the queries you will find that more or less of the "data rolling" needs to be done in the application level so it isn't just a matter of cutting and pasting SQL query text.

Ever do data replication between different versions of the same database server brand running on the same machine?

This is the kind of pain that is driving the stampede towards virtual servers.

Not only does it help you with standard DB functions (connecting, queries, inserts, updates, etc.), it helps you develop quickly for multiple database systems.

I agree, the test case given in the article about using one DB in a test environment and another in production could have been stated another way. However, there are many companies the develop web applications for many clients, all of which use different DB systems. In order to get a good time-to-market implementation, you'll need a good DB abstraction layer. I've used Zend_Db in Zend's framework quite a bit. It's very efficient and easy to implement. http://framework.zend.com/manual/en/zend.db.html.

Need an ORM? Doctrine is a very good choice. http://www.phpdoctrine.org/

Not only that, IBM and Oracle have PDO built into their DB systems. IBM has built in connection pooling in their DB2v9 system that has been optimized for PHP. Oracle has done the same with their 11g DB.

Needless to say, PDO is a VERY good thing.