Future Proofing database connection/functions

[JD*]

Hello all,

 

I am trying to make a determination about the best way to move forward with my database code for both personal projects and for the company I work for. For my own projects, I used to use mysql functions but have started to switch over to PDO. The company I work for is still using mysql functions and they are a bit wary about switching over to either mysqli or pdo, as they have a lot of code to go through and they don't want to make a bad decision.

 

So I started working on a database class that would replicate all of the mysql functions they were used to (fetch_assoc, fetch_array, num_rows, etc) and decided to make it so that, via a config, you could use mysqli OR pdo and then, in each function, it would do it's best to get the expected result. This way, the code for the company would only ever have to do something like:

 

$db->query($sql);

if($db->num_rows() > 0)

 

etc...

 

But the more I read up on PDO (which I have been using in a more proceedural way), it seems like this is already a wrapper, so in effect I'm wrapping a wrapper.

 

So, bottom line, what are others doing to future proff their database code? I like the idea of a class with generic function names, because if there is ever another style to use (mysqlii?) we can just write up the proper functions inside of the existing class and they'll work without a hitch. But is this something that pdo already delivers? I know it's good for dealing with multiple types of databases (mysql, mssql, oracle) but this company will only ever be working with mysql, so I don't have to go overboard with considerations for that.

 

Thanks for any help/advice!

 

JD

[kicken]

I don't think PDO will be going anywhere like mysql_* did. PDO was designed to be just a normalized API without and specific database association. The database association is handled by whichever driver you decide to load into it. If there were another instance of something like the mysql -> mysqli switch that needed to be done, it would likely just be implemented as just a driver change, eg:

//Rather than
new PDO('mysql:...');
//You'd do
new PDO('mysqli:...');

I simply rely on PDO for my code. I trust that it won't be needing replacing.

[vinny42]

 

I like the idea of a class with generic function names, because if there is ever another style to use (mysqlii?) we can just write up the proper functions inside of the existing class and they'll work without a hitch.

 

You will always have your own class that wraps something, even PDO, because you'll always want to implement some logging, auditing, performance monitoring etc in the most central location, which will be the the database class.

 

 

I know it's good for dealing with multiple types of databases (mysql, mssql, oracle) but this company will only ever be working with mysql, so I don't have to go overboard with considerations for that.

 

PDO does nothing for supporting multiple databases except use the same function names for the various things you can do to a database. Every brand of database has it's own dialect and PDO does not translate that. Adding a database brand always requires separate PHP code.

 

If you're going to move away from mysql_* then you might aswel go for PDO, which has a slightly more logical interface. (and that would be the only reason, for me )

[KevinM1]

Given that the mysql_* functions are soft deprecated, your company really should take the time to modernize, if they want to keep up-to-date with PHP releases and the bug fixes and security patches they have.

 

Have you (or your company) considered looking into something like Doctrine? Why roll your own and go through the growing pains associated with it when you can grab an enterprise solution off the shelf and integrate it?

[vinny42]

 

Why roll your own and go through the growing pains associated with it when you can grab an enterprise solution off the shelf and integrate it? 

 

In the case of Doctrine I'd say: because ORM shoiuld be chosen carefully, very carefully.

In the case of any other off-the-shelf solution; depends on how much work it is to migrate.

 

Why a homemade solution; because you can make it follow the mysql_* interface so you don't have to change any of your existing code. You could just search and replace mysql_ with mydbclass_ and that would be that.

[JD*]

Thanks for all of the helpful answers. I guess that I'm going to go with my first instinct to make my own class that wraps around the existing functions. This way I can sell it as "Hey, just replace mysql_num_rows with $db->num_rows() and we'll never have to update that line again, we just make sure the num_rows function inside of db.php returns what we want."

 

As for using an existing product, I would love to, but this place has gotten burned one too many times by adopting frameworks that have suddenly gone out of style. It's like a Murphy's Law thing: once they adopt it, the project implodes, so we don't want to jinx it.