That's absolutely true, but I was using the generic MySQL lib as a kind of common-ground illustration. The actual point translates just as well to any other DB library. Establishing a connection to the server and issuing queries takes a lot of time and often times it's done for all requests even if some of them don't need fresh DB data.
Re:PHP Pitfalls
by numbsafari on Tuesday December 04, 2012 @11:25AM
(#4871631)
Yeah, except you're talking about PHP Pitfalls and failed to mention and then fell victim to and perpetuated the #1 Pitfall of PHP: Legacy Cruft.
PHP's libraries are full of Legacy Cruft that any other sane system would have deprecated and eliminated during a major revision transition.
The wholly inefficient and unsafe legacy MySQL lib is one of the primary examples.
Good on you for at least mentioning parameterized statements, but you didn't really follow through. You then go on to confuse the situation by talking about the old API.
Instead, you should have just said "Using this old API is a horrible idea. Don't. Ignore every guide or tutorial that does."
PHP has evolved considerably from its roots. The #1 problem with PHP is that it still lives in its parent's basement and hangs out with the same losers it met in Kindergarten.
Couldn't this be seen as a "benefit" - not having to rewrite code after every major release?
Re:PHP Pitfalls
by TazeTSchnitzel on Tuesday December 04, 2012 @12:12PM
(#4871895)
You still do. They do break things with each major release, sometimes in a big way. (Fatal-by-default errors for some types of "bad" OOP code and not setting the timezone in PHP 5.4, for example). Just not as much as some other languages.
Re:PHP Pitfalls
by numbsafari on Tuesday December 04, 2012 @11:10PM
(#4874818)
You are more than welcome to not fix all of the security holes created by and allowed to exist by the old API.
Script kiddies everywhere will "benefit".
I don't really agree with that criticism. The first DB example I used was all about parameterized queries. Still, that doesn't absolve people from at least thinking about escaping stuff, that's why this other example is in there. But I get your point, I'll append the section to make it clearer why I'm referencing a legacy library.
Actually you should avoid using both mysql_pconnect and mysql_connect, because they're both functions from the deprecated old mysql library of database functions. The preferred way to deal with MySQL databases in 2012 is to use either PDO (http://php.net/manual/en/book.pdo.php) or the "improved MySQL" library (http://php.net/manual/en/book.mysqli.php), both of which are better architected and give you access to things like prepared statements that the old mysql library does not.
There's really no good reason to be using the old mysql library at this point. Unfortunately, however, there's a vast amount of ancient PHP tutorials, code snippets, and other copypasta floating around out there that uses it, so people who don't know better still pick it up.