I\'m trying to create a simple to use singleton class to connect to mysql database and do queries, the code works fine and i haven\'t had any problems with it, but since I\'
I think a singleton can be OK for a connection manager, but not for a connexion itself.
You never know when you'll need to have an extra connection for a specific part of your development. Let say you suddently need to add a synchronisation with a remote database.
A connection manager (who can manage multiple connection) can be a singleton. A connection itself; no.
You connection manager should also be able to load "Drivers", so that you'll be able to instanciate a MySQL connection and the day you need msSQL, sqLite or anything else, you're able to add the needed drivers.
Singletons are bad news.
You're better off looking at dependency-injection instead, as it resolves the above issues.
The only positive argument I've heard for the Singleton design pattern in PHP was from a developer who implemented a Singleton database connection in conjunction with a Memcached object. I didn't actually get a chance to look at the code and performance but he was able to put forward a coherent argument.
Personally I don't believe that the Singleton design pattern is very relevant to PHP, which is largely stateless anyway (as pointed out before each request will have a singleton).
This pattern will be fine because the singleton will only apply to the current user session. The decision really comes down to what your priority is. If you want faster performance for the user then you want to allow more database connections per user, but if you want to limit how hard your database gets hit then the singleton gives you a good middle of the road.