Php uses copy on write, so if u dont alter an an inputs value it wont consume more memory

I personally think short tags are awful. And the support of is something I frown at. Equals sign should be an assignment, so one could read this as “Question mark equals something?!”. Are we so lazy, that writing out is too much for us to bear?

If the second database is on the same server, then that would work OK. But if not, there’s where the problem lies. It’s been an issue I’ve hit several times.

Using references does save memory when assigning large variables/arrays.
I have added a test code in point #24 to show that.

I agree with your and EllisGL’s views on unit testing with singletons. They are to be avoided for proper unit testing.

Short tags should be avoided because :

1. If short tags are disabled on a certain hosting , then the whole code will be echoed to screen.

Php 5.4 has enabled “short echo tags” <?= by default , not "short tags" <? .
So if 'short_open_tag = Off' in php 5.4 the code inside short tags will not run , just echo as plain text.

PHP uses copy-on-write internally. Using references does not save memory. Only use references you want to change the input variable of a function.

“Testing , development and deployment are different scenarios. The database class can be configured to be non-singleton during testing and singleton when deployed. Its just a change of configuration.”

Would that not defeat the entire purpose of unit testing, if you’re going to deploy different implementations to production than what you actually test ??? Sorry, but I must agree with EllisGL, singletons are a no-go if you want proper/strict unit testing. There are many more elegant and testable ways to achieve the exact same behavior without touching static properties. (giving them a parent scope and “lazy loading” the connections for example).

Next I would like to know why you state “Do not use short tags”. Is there a reason for this ? As of 5.4 they’re even enabled by default.

For the rest I really enjoyed this article, great job.

“One being if you set it up wrong, you are tied to only one database through out your app.”

– If needed then there should be multiple database connections , but as long as working with a single database there is no need. Its not a rule, just an approach, the use of which very much depends on the requirements.

Moreover, its possible to work with multiple databases using a single connection :

INSERT INTO `database2`.`table_name` (………

It will work even if your mysqli object is connected to `database1`

“The second one is Unit Testing. Makes it damn near impossible to test it properly.”

– Testing , development and deployment are different scenarios. The database class can be configured to be non-singleton during testing and singleton when deployed. Its just a change of configuration.

I would avoid using singletons for a number of reasons. One being if you set it up wrong, you are tied to only one database through out your app. The second one is Unit Testing. Makes it damn near impossible to test it properly.