Преимущества mysqli гарантируют переписывание большой, работающей системы?

Question

Я прошу прощения, если этот вопрос является дубликатом. Сначала я прочитал многие другие mysqli вопросы , но ни один из них не был точным дубликатом.

Я старший разработчик проекта, над которым моя компания работает 4+ года. Это большая фреймворковая система PHP MVC с модулями для системы CMS, системы электронной коммерции и многого другого. Всего мы говорим о 1583 файлах и ~ 407 912 строках кода (исключая комментарии и пустые строки).

В системе используется собственная система, подобная активной записи, которую мы создали с нуля, и она используется практически в каждом модуле системы. Он был построен с использованием старых функций PHP MySQL, а не новых функций MySQL или PDO. PDO немного излишним, потому что, как компания SaaS, мы контролируем инфраструктуру и будем использовать MySQL в обозримом будущем, поэтому нам не нужна абстракция базы данных. Но ответы здесь, а также в документации по PHP используют все более и более сильный язык в отношении mysql vs mysqli:

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

Примечание

Если вы используете MySQL версии 4.1.3 или позже настоятельно рекомендуется что вы используете расширение MySQL вместо этого.

Поскольку мы использовали старые функции mysql, новый код был тщательно проверен на наличие ошибок внедрения SQL. Это было проверено нашими сотрудниками, так что, возможно, мы могли что-то пропустить, но я уверен, что мы покрыты Поскольку система использует функции mysql в коде, новый код должен следовать этому соглашению; мы не можем перейти на MySQL, когда мы идем ...

Есть ли преимущество в переписывании всей системы, чтобы вместо нее использовать mysqli? Или лучше спросить, будет ли выгода стоить довольно больших затрат? Или это то, что мы должны учитывать, когда мы делаем большую переделку (в следующей основной версии)? Я придерживаюсь мнения, что если это не сломано, не чинить это ... но я просто упрямый?

Answer 1

PDO немного излишним, потому что, как SaaS-компания, мы контролируем инфраструктуру и будем использовать MySQL в обозримом будущем, поэтому нам не нужна абстракция базы данных.

Это именно то, на что вы должны обращать внимание ... непредсказуемое будущее.

Что вам действительно нужно определить, так это то, насколько гибко ваше приложение ... действительно ... и нужно ли этобыть более гибким.Если он спроектирован правильно, он не должен быть таким трудным для миграции или дорогостоящим.Если это действительно так сложно / дорого, возможно, сейчас самое подходящее время, чтобы внести изменения и провести некоторый ре-факторинг, пока вы на нем.Таким образом, когда система должна быть перемещена на новую более быструю платформу БД, или обновлена, или улучшена;изменение становится скорее заменой «перетаскивания» вместо полной перезаписи.

Answer 2

Я не знаю, стоит ли переодеваться, чтобы просто переодеться.Я бы серьезно подумал о переходе на следующую серьезную ревизию.

Хотя - вам, вероятно, лучше перейти на уровень абстракции базы данных, так что если вы сделаете изменения (или они будут иметь функции mysql_super_duper ())вам не нужно пересматривать весь ваш код - только код абстракции.