Как эффективно хранить SQL в PHP-приложении?
У меня есть приложение, которое имеет много запросов, которые повторно используются в нескольких местах. Каков наиболее эффективный способ их хранения? Мой инстинкт состоит в том, чтобы хранить их в массиве в классе, то есть:
$sql['report 1'] = "SELECT this FROM that WHERE expression";
$sql['report 2'] = "SELECT this FROM that WHERE expression2";
и т.п.
Другой разработчик, который работал над этим проектом, сделал это с помощью переключателя:
switch($query){
case 'report 1':
$sql = "SELECT this FROM that WHERE expression1";
break;
case 'report 2':
$sql = "SELECT this FROM that WHERE expression2";
break;
}
$result = runquery($sql);
У меня была еще одна идея, что каждый отчет должен быть отдельной функцией:
function report1(){
// run the query here
return result;
}
function report2(){
// run the query here
return $result;
}
Я предпочитаю метод массива, потому что он выглядит как более чистый код, но поскольку существует большое количество запросов, разве это не расточительно с точки зрения использования памяти? Разве все запросы не останутся в памяти?
Метод переключения переключателя кажется немного громоздким. Каковы преимущества и недостатки этих методов? Есть ли метод, который выделяет «лучший способ» сделать это? Или, возможно, другой метод, который я не рассматривал?
Решение
Я столкнулся с этим вопросом очень давно. Болевая точка, которая заставила нас решить этот вопрос, заключалась в том, что мы видели много дублирования в SQL-запросах, разбросанных по всему коду.
У нас была собственная доморощенная инфраструктура MVC, и у нас были простые классы-обертки для доступа к базе данных, но мы регулярно находили один и тот же запрос SQL в нескольких классах моделей.
В то время мы чувствовали, что нет необходимости выделять SQL-код в отдельные функции на уровне доступа к данным — это будет чище, но это приведет к созданию целого нового «уровня» в архитектуре, и что дополнительный уровень сложности будет не обязательно. Мы также не хотели переработать классы моделей, чтобы они были более детальными — у нас было много нехватки времени, и команда почувствовала, что базовая структура не вызывает никаких проблем — это просто дублирование SQL-запросов, которые причинить боль.
Наше решение было довольно простым. Мы создали файл PHP с переменными для каждого запроса (это был не массив, как вы описали, только одна переменная на запрос). Мы использовали условные обозначения в верхнем регистре, чтобы указать, что это «константа» Мы обильно заваливали файл SQL комментариями и использовали соглашение об именах, чтобы помочь разработчикам понять намерения, а не механику. Что-то вроде:
$REPORT1_GET_THIS_FOR_EXPRESSION = "SELECT this FROM that WHERE expression";
$REPORT2_GET_THIS_FOR_EXPRESSION2 = "SELECT this FROM that WHERE expression2";
Мы включили этот файл PHP во все классы моделей. Да, это занимает память, но не так, как вы могли заметить — на самом деле, использование памяти, вероятно, было ниже, потому что те же строки не дублировались в других исходных файлах во время выполнения.
Это работало хорошо для нашего (небольшого) проекта, с 3 или около того разработчиками, все работали вместе в одной комнате. Наш начальник ценил время выхода на рынок за ремонтопригодностью или расширяемостью, и это сработало довольно хорошо. Код был читабелен, и мы могли изменить SQL-запрос в одном месте и исправить множество ошибок.
Я бы не стал использовать решение «switch». Каждый оператор SQL состоит из 3 строк кода (в отличие от одной строки кода) и включает в себя логический оператор, который может ошибаться (цикломатическая сложность будет через крышу). По моему опыту, меньше кода почти всегда лучше …
Другие решения
Других решений пока нет …