Необработанный SQL против запросов на основе ООП (ORM)?

Question

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

РЕДАКТИРОВАТЬ : Проект относится к одному из типов, в котором пользователю не предоставляется мой контент, но он генерирует контент, и проект находится в сети. Таким образом, объем контента зависит от количества пользователей, и если в проекте даже 50000 пользователей, и, кроме того, каждый пользователь может создавать контент или читать контент, то какой подход будет наиболее подходящим?

Answer 1

Если у вас нет (или ограничен) опыта работы с ORM, то для изучения нового API потребуется время.Плюс, вы должны иметь в виду, что жертвуйте скоростью ради «магии».Например, большинство ORM выбирают подстановочный знак '*' для полей, даже когда вам просто нужен список заголовков из таблицы Articles.

И ORM всегда будут терпеть неудачу в нишевых случаях.

Большинство ОРМ (основанных на шаблоне ActiveRecord ) с точки зрения ООП крайне несовершенны.Они создают тесную связь между вашей структурой базы данных и классом / моделью.

Вы можете думать об ОРМ как о техническом долге .Это облегчит начало проекта.Но по мере усложнения кода вы начнете сталкиваться со все большим количеством проблем, вызванных ограничениями в API ORM.В конце концов у вас возникнут ситуации, когда невозможно что-то сделать с ORM, и вам придется начинать писать фрагменты SQL и напрямую вводить операторы.

Я бы посоветовал держаться подальше от ORM и реализовать DataMapper шаблон в вашем коде.Это даст вам разделение между объектами домена и уровнем доступа к базе данных .

Answer 2

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

Это не значит, что вы не должны проектировать свойства своего приложения, но опять же: если использование ORM не дает вам никакой выгоды, то зачем вам его использовать?

Answer 3

Для скорости разработки я бы выбрал ORM, особенно если большая часть доступа к данным - CRUD.

Таким образом, вам не нужно разрабатывать SQL и писать процедуры доступа к данным.

Масштабируемость не должна пострадать, хотя вам необходимо понимать, что вы делаете (вы также можете повредить масштабируемость с помощью необработанного SQL).

Answer 4

Если проект ориентирован на: - редактирование данных (как при просмотре простых таблиц данных и их редактировании) - производительность (как при разработке самого быстрого алгоритма для выполнения простой задачи)

Тогда вы можете перейтис прямыми командами sql в вашем коде.

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

Тем не менее, было бы полезно получить больше информации, как: - Что вы подразумеваете под частым (как часто)?- Какая производительность вам нужна?

РЕДАКТИРОВАТЬ

Похоже, вы предоставляете какую-то услугу CMS.Держу пари, ты не хочешь начинать наполнять свой код SQL.Предложение шаблона @ teresko кажется интересным, отделяя логику вашего приложения от БД (что всегда хорошо), но предоставляя возможность настраивать каждый запрос.Тем не менее, добавление слоя, который заполняет объекты памяти, может занять больше времени, чем простое использование результата базы данных для написания вашей страницы, но я не думаю, что в вашем случае небольшое различие должно иметь значение.

Я бы посоветовал выбрать хороший шаблон, который разделяет вашу бизнес-логику и dataAccess, например, предложенный @terekso.

Answer 5

Это немного зависит от масштаба времени и ваших текущих знаний о системах MySQL и ORM. Если у вас мало времени, просто делайте то, что вы знаете лучше, чем тратите время на изучение нового набора кода.

Со временем система ORM, такая как Doctrine или Propel, может значительно повысить скорость вашей разработки. Когда схема все еще сильно меняется, вы не хотите тратить много времени только на переписывание запросов. В системе ORM это может быть так же просто, как изменить файл схемы и очистить кеш.

Затем, когда дизайн успокаивается, следите за производительностью. Если вы используете ORM, а ваш код является полноценным ООП, переход на SQL-запрос по одному не является большой проблемой.

Это замечательная вещь в кодировании с ООП - такое решение не должно связывать вас вечно.

Answer 6

Я бы всегда рекомендовал использовать некоторую форму ORM для вашего уровня доступа к данным, поскольку в аспект безопасности было потрачено много времени. Это само по себе является причиной, чтобы не отказываться от собственных, если только вы не уверены в своих навыках защиты от внедрения SQL-кода и других уязвимостей.