January 13th, 2013, 05:38 PM
So I'm a couple weeks and several thousand lines of code into my current project. I'm still learning PHP and it has recently come to my attention that MySQL functions are being deprecated. Unfortunately I need to go back and change everything MYSQL related to MySQLi.
I feel a little stressed with a long road ahead of me and not knowing much beyond the basics of OOP.
Is it possible to write the four basic CRUD functions inside a class and simply pass the SQL to the given function needed as a variable, or will I be required to write out queries and while loops for every single query?
The latter seems like a daunting task and very messy compared to just using the old MySQL syntax that is being phased out.
Any help or suggestions would be greatly appreciated.
January 13th, 2013, 07:09 PM
first of all: If your current database code is OK and secure (with every value wrapped in mysql_real_escape_string), you do not need to switch to MySQLi now. The old extension is indeed deprecated, but that doesn't mean it will be removed tomorrow. The PHP developers are well aware that this would break many websites, so they will certainly keep the extensions for some more years.
Personally, I'm a strong advocate of MySQLi and PDO, but only if you actually use the new features (like prepared statements). If you merely replace mysql_query() with mysqli_query(), you haven't really gained anything.
So don't panic, don't rush things. If you think you need an update, do it gradually on a test system and replace the old query functions "by hand" so that you can use the new features.
A database wrapper would certainly make sense in order to be independend of the underlying extension. But you don't need to write your own, because PHP has one already: PDO. Unlike MySQLi, it isn't bound to a particular database system. You can use it with all mainstream DBMS like MySQL, PostgreSQL, Oracle etc.
January 13th, 2013, 07:15 PM
Thanks that really put my mind at ease. I'll finish up the project and work on having a solid understanding of PDO prior to implementing the switch.
Comments on this post
January 13th, 2013, 07:39 PM
Everything that Jacques1 said is very true. But I thought that I should mention that mysqli supports object oriented calls AND procedural calls. Thus, if you have written a lot of procedural code, you do not have to replace it all with OO code to use mysqli. You can take advantage of all the new functionality and still use your procedural code. I found myself in exactly your position a few months ago and am slowly converting from mysql to mysqli while sticking to procedural code. i found this web site very useful: http://www.phpknowhow.com/mysql/mysqli-procedural-functions/
January 14th, 2013, 04:24 AM
if your editor allows you to do replace in files/project then you could simply replace all
mysql calls with mysqli equivalent calls
January 14th, 2013, 04:42 AM
There are a few big differences. Like procedural mysqli requires the connection to be passed, and the order of arguments generally has the link first (like mysql_query() has query+link while mysqli_query() has link+query).
Originally Posted by paulh1983
January 14th, 2013, 07:36 AM
... and like I already said above: You gain absolutely nothing from simply replacing the function calls. I mean, it's not like mysqli_query() was somehow "better" than mysql_query().
If you do an update, then do it right and actually use the new features. Otherwise it's just "Using the latest stuff makes me feel better".
January 14th, 2013, 08:45 AM
This is where (and why) developers write in database abstraction layers.
If you had written your own code/function to wrap around your mysql_* implementation then you'd only need to change your code in one place.
Design patterns like MVC also come into play here - having all your database code/functions/connectivity all laid out in one folder of your project then at least you know where all your code is.
If you have "spaghetti" code with php and html all over the place with database connections and queries thrown in as and when they're needed (almost ad hoc style) then your code base is going to be a nightmare to maintain at any stage, regardless of database functions (this is just your first taste of it).
I don't necessarily recommend MVC, as i don't think it's always fit for purpose on websites, but the principle is a good fit to a lot of situations requiring logic, data and display.