I have developed an open source PHP application and currently it uses both the MySQLi or MySQL extension for backwards compatibility. I'm wondering about switching it over to only be compatible with MySQLi since PHP now no longer supports the MySQL. Another reason I'd like to get away from supporting both MySQL and MySQLi is that I'm basically using MySQLi the same way I do as with the old MySQL extension. Can anyone explain to me if this is a good or bad idea?
MySQLi Usage – Is It Safe?
backward compatibilitycompatibilityMySQLPHP
Related Solutions
In a lot of situations, the simple technique of "last writer wins" can be sufficient.
Last writer wins means that the last person to save has his changes kept; any changes made while that person was editing are lost.
While this might seem a crazy approach, consider that in many systems the source of change is to synchronise with the real world.
Consider a system listing customers with their addresses and phone numbers. Imagine that one of their customers, Mary, has recently moved house. She sent in a change of address card to your compand. Her husband, John, didn't know about this and has phoned in to update details through the customer centre. Coincidentally, the change of address card is being processed concurrently with the phone call.
Which change should be kept? It doesn't matter - because both edits will be changing the house address to the same value.
You also need to keep in mind the potential frequency of concurrent updates - it's actually pretty unlikely that the phone call and processing of the change of address card would happen at the same time. If the card was processed first, John would find the details already correct when he called; if the card was processed last, the operator would find the details already correct. In either case, no conflict.
It sounds fine, but rarely works out in practice; people are extremely reluctant to change running code, and even for new, green-field projects they are very reluctant to switch way from a language/version that they already know.
Changing existing, running code that "works fine" is not something that ranks high on any project's priority list. Rather than applying effort to things that the managers thought had been paid for already, just to be able to upgrade to a newer release of a language or platform, they will decree that the developers should just stay on the old release "for now". You can try to entice your users with great features only available in the new release, but it's a gamble where you risk decreasing your user base for no clear gain for the language; cool, modern features cannot easily be weighed against the price of fragmented installation base in popular opinion, and you run the risk of getting a reputation for being an "upgrade treadmill" that requires constant effort to keep running when compared to more relaxed languages/platforms.
(Obviously, most of this doesn't apply to projects written by hobbyists just for their own pleasure. However (here be flamebait...) PHP is disproportionally rarely chosen by hackers because it's such a pleasure to write with in the first place.)
Best Answer
If you are going to switch anyway, you should really consider going with PDO instead of MySQLi.
The main benefit, would be that your application would be able to work with any of the 11 other database backends supported by PDO, with minimal fuss. This might not be a priority for you, but since this is an open source application there's little reason to not try and make it as flexible as possible. Also, you'd be able to use named parameters in your prepared statements (MySQLi supports prepared statements, but not named parameters).
In any case, moving away from the
mysql_*
functions is a very good idea. These days, it's just a relic of the (dark) past, and unless backwards compatibility is an inescapable requirement there's absolutely no reason to use it.