1 |
Размер исходного кода |
10К |
50К и более. Больший размер кода с большим количеством логики может содержать больше ошибок. |
2 |
Порог вхождения программиста перед началом работы |
Меньше. Достаточно изучить несколько простых типов меток-заменителей и одно правило условного блока |
Больше. Нужно изучить десятки методов с их параметрами. |
3 |
Перегенерация моделей каждый раз при изменении схемы БД |
Не нужно |
Нужно. Это занимает лишнее время, в логике генератора могут быть ошибки. |
4 |
Быстрое создание нового запроса к БД |
Да. Только расстановка меток-заменителей в SQL запросе |
Да для простых запросов. Но сложные SQL запросы необходимо переписывать после их отладки в набор методов ORM/QB, это лишние затраты времени. |
5 |
Быстрая модификация существующего запроса к БД |
Да. SQL запрос можно дописать сколько угодно сложным SQL кодом. |
Нет. При усложнении логики возможностей ORM может не хватить и тогда нужно переписывать обратно в SQL. Сложный запрос в QB может стать слабо читабельным и трудноподдерживаемым. |
6 |
Скорость генерации SQL |
Быстрее. Простой парсер без использования регулярных выражений работает очень быстро. Парсер на базе рег. выражений работает не медленнее ORM или QB |
Медленнее. Ещё один слой абстакции с дополнительной логикой, которая может содержать ошибки. |
7 |
Оптимальность генерации SQL |
Да. Выполяется именно тот запрос, который задумал разработчик. |
Нет. Вместо 1-го SQL запроса их может быть десятки, что плохо сказывается на общем времени выполнения. |
8 |
Поиск медленных запросов для оптимизации |
Легче. SQL запрос можно найти в исходном коде по совпадению фрагментов |
Труднее. Запрос генерируется и найти это место в коде трудно, если ORM или QB не записывает перед запросом в комментарий указатель на место в исходном коде (на практике такого нет). |
9 |
Результат в виде вложенных объектов |
Да. За 1 SQL запрос можно получить результат сколь угодно сложной структуры, возвращая JSON и затем декодируя его. По сути это аналог объектов, хотя и не полноценный (есть свойства, но нет методов). Но методы могут не понадобиться так так все данные, скорее всего уже получены в 1-м SQL запросе. При острой необходимости можно сделать экспорт данных в полноценные объекты |
Да. Но на каждый объект будет как минимум 1 SQL запрос, что плохо скажется на производительности. |
10 |
Кэширование запросов (в памяти приложения) |
Хуже. Кеширование на уровне приложения работает только для запроса целиком для всех получаемых объектов. Но кэширование отдельных объектов может не понадобиться, так так все объекты уже получены в 1-м SQL запросе. Так же БД сама умеет кешировать данные в памяти. |
Лучше. Продвинутые ORM или QB могут кешировать каждый экземпляр объекта независимо. Но инвалидация кеша в приложении обычно сложная и может содержать ошибки. |
11 |
Скорость (а так же удобство и гибкость) разработки |
Хуже. Могут присутствовать дубликаты SQL кода. В случае изменения логики нужно править во многих местах. Но в этом случае такая множественная правка будет одновременно валидацией необходимости правок в каждом месте |
Лучше. Одинаковые части выносятся в отдельные методы объектов. С объектами легче манипулировать. |