4

I apologize if this question is a duplicate. I have read many other mysqli questions first, but none seemed to be an exact duplicate.

I am the senior developer on a project my company has been working on for 4+ years. It's a large PHP MVC framework system with modules for a CMS system, an eCommerce system, and more. In total we're talking 1583 files and ~407,912 lines of code (excluding comments and blank lines).

The system uses a propriety active-record-like system we built from the ground up, and it's used in almost every module of the system. It was built using the old PHP mysql functions, not the new mysqli functions or PDO. PDO is a bit overkill because as a SaaS company we control the infrastructure and we'll be using MySQL for the forseable future, so we don't need the database abstraction. But answers on here as well as the PHP documentation have been using stronger and stronger language regarding mysql vs mysqli:

http://ca3.php.net/manual/en/mysqli.overview.php:

Note:

If you are using MySQL versions 4.1.3 or later it is strongly recommended that you use the mysqli extension instead.

Because we were using the old mysql functions, new code was thoroughly reviewed to check for SQL injection errors. It was reviewed by our staff, so it's possible we could have missed something, but I'm fairly confident we're covered. Because the system uses mysql functions at the code, new code must follow that convention; we can't migrate to mysqli as we go...

Is there a benefit in rewriting the entire system to use mysqli instead? Or better asked, would the benefit be worth the fairly large cost? Or is this something we should consider when we do a major rework (in the next major version)? I'm of the mindset that if it ain't broke, don't fix it... but am I just being stubborn?

Community
  • 1
  • 1
Josh
  • 10,961
  • 11
  • 65
  • 108
  • Oh, wait, that file/line count includes JavaScript code. Please stand by while I figure out how to exclude .js files... – Josh Sep 02 '10 at 14:22
  • 2
    You shouldn't need to rewrite everything. You said you developed a *"propriety active-record-like system"*, so this should be the only thing that needs change, because with proper design all the rest of you code shouldn't use `mysql` directly. instead it should call functions of your AR-System – jigfox Sep 02 '10 at 14:25
  • @jigfox: It's similar to Ruby's ActiveRecord system, where I can select based on SQL `WHERE` clauses or entire SQL statements. So all those statements across all modules would need to be rewritten to use Prepared Statements... – Josh Sep 02 '10 at 14:28
  • @meagar: Thanks for the edits. I thought backtick was acceptable to use for the name of a language function; maybe bold or italic would be more appropriate for this usage. – Josh Sep 02 '10 at 14:32
  • 4
    If you are going to switch to a never database class than you ought to use PDO, not mysqli. It adds inter-database abstraction and has cleaner API. (And don't tell me, that you are sure that you always will be using MySQL. You simply can't know the future.) – NikiC Sep 02 '10 at 14:33
  • 2
    No they don't need all to be rewritten, only if you want to use prepared statements everywhere, but you can use [`mysqli_query`](http://www.php.net/manual/en/mysqli.query.php) to make direct query, than you use `mysqli` the same like `mysql`, and then you can use whatever you want prepared statement for new things and the old ones should work as before, an can be migrated if needed. – jigfox Sep 02 '10 at 15:05
  • @jigfox: Well that sounds like a perfect answer to my problem! But I can't put a purdy green check mark next to a comment ;-) – Josh Sep 02 '10 at 15:09
  • If you want the advantages of prepared statements without changing your existing code you could also rewrite your active record class to create them internally. That's what I did :) – Michael Clerx Sep 02 '10 at 15:25

2 Answers2

1

I don't know if it's worth changing over just to change. I'd seriously consider changing over for your next major revision.

Though - you're probably better to move to a database abstraction layer, so if you do change (or they come out with mysql_super_duper() functions), you don't have to revisit your entire code - just the abstraction code.

Quasipickle
  • 4,383
  • 1
  • 31
  • 53
  • 1
    I've been waiting for `mysql_super_duper()` for way too long! :-) -- In seriousness I think you're right, if and when we rewrite, I'll add abstraction so these changes in the far future would be easier. – Josh Sep 02 '10 at 14:47
1

PDO is a bit overkill because as a SaaS company we control the infrastructure and we'll be using MySQL for the forseable future, so we don't need the database abstraction.

That is exactly what you should be looking out for... the NON-forseable future.

What you really need to define is how flexible is your app... really... and does it need to be more flexible. If it is designed correctly, it should not be that difficult to migrate / or costly. If it truly is that difficult / costly, maybe now is the right time to make the change and do some re-factoring while you are at it. This way, when the system needs to be moved to a new faster DB platform, or updated, or improved; the change becomes more of a "drag-n-drop" replacement instead of a complete rewrite.

Chuck Burgess
  • 11,600
  • 5
  • 41
  • 74