And the advantabes of PDO are again?

Okay so someone went and explained way back when why ADO was an enhancement over DAO in the old vb5/6 days (Beacon from memory or it could have been someone else).

Not seeing a lot of advantages to PDO for MySQL queries over the traditional MySQL functions. Still have to hack out great wads of sql etc. Anyone actually found the killer reason to go to PDO?

We're doing so regardless, but not seeing it as the single bestest ever solution to multiple database type processing, you still need to be all over the various SQL implementations.

I don't deal with web garbage much, but oddly I was exposed to this recently. Honestly, it seems like PHP's attempt at something like ADO.NET. A common framework for working with any database type so you're not dealing with the peculiarities of any one database object; i.e. the connect function in MySQLi could be completely different from the connect function in... I dunno... Oracle's library.

Still, from getting to play with it briefly, it seemed like a tremendous waste of time since you're still dealing with large connection strings and gobs of SQL... both of which will most likely be customized for their database engine preventing easy migration regardless.

Then again, ADO.NET can suffer from the same problems. Ever have to completely rewrite a data layer because the database provider allowed you to chain multiple SQL lines together and pass them as a single command... thus the entire system was programmed with that functionality... and the new provider you're switching to won't?

What definition of PDO do you have? The one I have is Pacific Decadal Oscillation, and it has a very great impact on the survival of salmon in the north Pacific. That's a pretty big advantage over ADO when it comes to salmon stocks, but it probably isn't at all relevant to your question.

Haha! Thanks for the laugh Shaggy, my day needed it. :D
No, it stands for PHP Data Objects. :)

Quote:

---

Originally Posted by Jenner

I don't deal with web garbage much, but oddly I was exposed to this recently. Honestly, it seems like PHP's attempt at something like ADO.NET. A common framework for working with any database type so you're not dealing with the peculiarities of any one database object; i.e. the connect function in MySQLi could be completely different from the connect function in... I dunno... Oracle's library.

Still, from getting to play with it briefly, it seemed like a tremendous waste of time since you're still dealing with large connection strings and gobs of SQL... both of which will most likely be customized for their database engine preventing easy migration regardless.

Then again, ADO.NET can suffer from the same problems. Ever have to completely rewrite a data layer because the database provider allowed you to chain multiple SQL lines together and pass them as a single command... thus the entire system was programmed with that functionality... and the new provider you're switching to won't?

---

Currently I'm not even sure there's any saving in connection strings

eg

$dbconn = new PDO("mysql: host=$hostname; dbname=$dbname", $username, $password)

Though I guess it lobs everything into an object, no doubt somewhere that will prove to be an advantage.

Interestingly enough - the .Net framework has distinct namespaces for each type of data access - SQL CE, MS SQL Server, Access...

Kind of indicates they abandoned the attempt at serving the masses with a single layer.

It's now expected that you will abstract the differences in data access by having a data-access-layer that is talked to by your business layer...

...that is if you have to talk to different DB backends.

I always considered it a silly holy grail that should not be attempted - being an MS SQL server programmer I fully push that envelope - using all it's features. I could never put an Oracle or MySql backend in it's place - the whole architecture realizes the backend's capabilities.

Anyone tells you differently is just blowing smoke...

Anyway - I'm more concerned about the salmon ;)

One of the 'killer reason' would be the use of "Prepared Statements", which the native MySQL functions won't provide.

Another one is, you can use more than 1 database type when you use PDO as it is a abstract layer. That is, you can use MySQL db or SQLserver, etc.. and only needs to change the connection string only. Whereas, native mysql functions are only for MySQL db.

Correct me if I am wrong.

:wave:

Yea, that's kinda what I was getting at akhileshbc, but each database still has it's unique changes to SQL itself. In MySQL, I can do a join on two tables on a key that has the same name in each table with: SELECT * FROM Table1 INNER JOIN Table2 USING(KeyField)

While this works great for MySQL, does SQLserver, Oracle or Pervasive support a USING() function? Probably not. Even if I do decide "I'm going to switch my system to using SQLserver, I got PDO as an abstraction layer, all I need to do is change my connection strings, right?" my application will still crash because my SQL statements will throw syntax errors, thus, you still have to recode it.

Quote:

---

Originally Posted by szlamany

...being an MS SQL server programmer I fully push that envelope - using all it's features. I could never put an Oracle or MySql backend in it's place - the whole architecture realizes the backend's capabilities.

---

That was my whole point. If you are writing robust SQL statements against a particular DB engine (MS SQL vs MySql vs MS SQL CE vs ACCESS) then you have to pick a particular SQL syntax and go with it.

If you are writing simple INSERT's and SELECT's - then a generic data layer like PDO might work.

Not in my world though...