SQL-запросы в циклах с PHP

Question

Итак, я недавно взял на себя обслуживание внутренней системы управления контентом, и оптимизация баз данных не является моей областью знаний.

Во всяком случае, несколько вещей выпало мне на глаза, когда я просматривал код.

PHP-код - это немного "спагетти с фрикадельками" без комментариев.

Но самое главное: насколько я могу судить, оригинальный программист решил полностью отказаться от объединения таблиц в коде базы данных (как неявном, так и явном).

Например, вот процесс отображения столбца страницы:

Получить список элементов из базы данных Для каждого элемента вызовите подпрограмму для проверки разрешений на отображение, а в случае успеха вызовите другую подпрограмму для получения html-данных элемента.

Каждая из подпрограмм фактически вызывает отдельный запрос для каждого элемента. И я полагаю, что этап разрешений включает запрос двух отдельных таблиц.

Производительность на самом деле не является проблемой в данный момент, и меня не просили разбираться с этим. Хотя запросы страниц немного медленны, на мой взгляд.

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

Или все не так плохо, как я думаю? Может быть, я просто слишком остро реагирую. Мнение эксперта будет оценено.

Answer 1

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

Что касается вашего вопроса о SQL-запросах, это может быть или не быть первым, что вам нужно изменить.

Answer 2

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

Answer 3

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

Что нужно принять во внимание:

Будет ли система расти со временем?И как?Если в сети будет больше пользователей, больше уверенности в системе - тогда есть повод для тревоги.Системы с плохим дизайном плохо масштабируются.

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

Но так как ваш вопрос стоит - перепишите некоторые вопросыубедитесь, что ваша БД нормализована и рефакторинг вашего кода.Скажите своему боссу, что это правильно, если вы собираетесь придерживаться системы.

Answer 4

Я думаю, что стоит переписать, пока у вас есть время для этого.Вы не хотите откладывать это, пока это не станет проблемой.Я говорю, пусть база данных делает то, что она делает лучше всего.В этом случае объединения таблиц, безусловно, будут работать лучше, чем несколько запросов в цикле.