What PHP database class do you use?

[ridiculous]

I'm looking through a variety of PHP database classes and was wondering if anyone could recommend a good one...

[JasonLewis]

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

[RichardRotterdam]

I used the joomla mysql database class and tweaked it so it supports sqlite,mysql and postgress. but there is no wrong or right in this. you prob can find some nice ones on phpclasses.org

[Daniel0]

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

 

If you ever have to tweak it then it's not very good.

[JasonLewis]

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

 

If you ever have to tweak it then it's not very good.

Yeah sometimes I don't need to. I've made it for myself in mind only, so I'm not fussed if I need to tweak it.

[Liquid Fire]

I use a custom built database class.  I use PDO for the backend.

[Daniel0]

I usually create my own then tweak it slightly for each different project. Sometimes I don't even need to tweak it. Why not write your own?

 

If you ever have to tweak it then it's not very good.

Yeah sometimes I don't need to. I've made it for myself in mind only, so I'm not fussed if I need to tweak it.

 

I think you missed the point (or maybe I didn't make it clear enough). There exist some common design principles. One of them is that you should code to an interface, not to an implementation. If you ever need to tweak your classes on a per-project basis then you have coded to an implementation. Another design principle is that your code should be closed for modification while being open to extensibility. You violate that principle as well if you have to tweak your class. This is true whether your application design exists on paper, in your mind, in a file on your computer or any other place.

[tibberous]

"One of them is that you should code to an interface, not to an implementation"

 

There isn't anything wrong with creating something specific to an application. If you wanted something so general it would work in all cases without modification you might as well just use the built in mysql functions.

 

Which is what I use btw - don't see any real advantage to wrapping everything in a class. Portability maybe, but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did, even with full-fledged wrapper.

[Daniel0]

You're missing the point as well. By coding to an interface you are ensuring that the components dependent on that class will not break if you change how everything works. As long as you leave the interface unchanged you can change everything else. Encapsulation is one of the fundamentals of OOP and application design in general. John (448191) has written a bit about it on the main site.

[448191]

There isn't anything wrong with creating something specific to an application. If you wanted something so general it would work in all cases without modification you might as well just use the built in mysql functions.

 

Which is what I use btw - don't see any real advantage to wrapping everything in a class. Portability maybe, but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did, even with full-fledged wrapper.

 

That's stupid.

 

If you have anything in a simple wrapper class that you can't use the next application, you messed up. And yes, it is true that even with a unified interface, the application's SQL may fail horribly when switching database vendors, or even server versions, but that is why database abstraction and ORM exist.

 

Of course I would never hope to convince anyone who promotes copy/paste coding of anything.

[Daniel0]

I forgot to mention this, but...

 

[...] but the chances we'd ever more from mysql are about as slim as the chances our application would work if we did [...]

 

That is a major flaw in your application design. You may use a few more hours in the initial programming phase and those hours will be well earned compared to the amount of hours you would have to waste because your lack of being able to take change into consideration. You may not want to change away from MySQL, but your client/boss might want to and then you're in deep shit if you haven't coded it properly from the start. When designing your app you should always take change into consideration (even if it's unlikely).

[corbin]

I had to switch something from MySQL to MSSQL once.  I wished I had used a wrapper.  It sucked!  (Although for most things a mass replace of mysql_ to mssql_ worked.  Just had a few kinks that weren't very fun.)

[Daniel0]

Well, there is not only a different in functions/classes in PHP, but each SQL vendor has its own proprietary features in addition to standard SQL. Foresightedness pays off.

[tibberous]

Maybe you guys are just in a different situation than me.

 

My company has one big project - our clients are the people that use it. I coded the entire thing by myself, with some minor exceptions (date pickers, lightboxes, mysql backup class, SMTP email class, FCK editor)

 

My boss doesn't care what database engine we use. We're using mysql because I wrote it with mysql. I always use mysql, because I've never ran into a situation where it didn't do what I wanted it too. Yes, if I went in tomorrow, and he said to use mssql, I'd be screwed. If he said make a multilingual version I'd be screwed too, but that doesn't mean I'm going to put all my strings in a big include file.

 

All the flexibility you write in to the codebase is a trade off - you have to weight the chance something will happen against the time it will take to account for it, sometimes the flexible approach is the best one, but I don't see how you can just say it is 'right'.

 

Oh well, I'm going to go copy a contact form, paste it into a control panel, and change variable names till I have a message board

[scottybwoy]

lol, sorry that last bit was funny.

 

Anyway, if you don't want to lose performance with an abstraction layer, I started off using MSSQL in my company, developed my own db class.  Since then I've just copied it for MySQL and changed it all to do the MySQL features.  You can do that for any db you like, call the functions the same and you just have a bunch of DB classes to choose from depending on what project you do, simple.