Хранимые процедуры или OR мапперы?

Question

Что лучше? Или использовать и или маппер с SP? Если у вас уже есть система с SP, стоит ли OR mapper?

Answer 1

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

Этот вопрос уже был рассмотрен Почему параметризованный SQL, генерируемый NHibernate, так же быстро, как и хранимая процедура?

Answer 2

Ничего хорошего нельзя сказать о хранимых процедурах. 10 лет назад возникла необходимость, но все преимущества использования sprocs больше не действительны. Два наиболее распространенных аргумента касаются безопасности и производительности. Дерьмо «отправлять вещи по проводам» тоже не работает, я, конечно же, могу динамически создавать запрос, чтобы делать все и на сервере. Сторонники sproc не скажут вам одну вещь - это делает обновления невозможными, если вы используете разрешение конфликтов столбцов в публикации слиянием. Только администраторы баз данных, которые думают, что они являются повелителем базы данных, настаивают на том, что их работа выглядит лучше, чем на самом деле.

Answer 3

На моей работе мы в основном выполняем линейку бизнес-приложений - контрактную работу.

Для этого вида бизнеса я большой поклонник ORM. Около четырех лет назад (когда инструменты ORM были менее зрелыми) мы изучали CSLA и разработали наш собственный упрощенный инструмент ORM, который мы используем в большинстве наших приложений, включая некоторые системы корпоративного класса, имеющие более 100 таблиц.

По нашим оценкам, этот подход (который, конечно, включает в себя много генерации кода) позволяет сэкономить до 30% времени в наших проектах. Серьезно, это смешно.

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

Например, пакетные операции с чрезвычайно высокой интенсивностью данных все еще должны обрабатываться в специализированных процессах, если это возможно. Вы, вероятно, не хотите отправлять 100 000 огромных записей по проводам, если бы вы могли сделать это прямо в базе данных.

Это тип проблемы, с которой сталкиваются разработчики-новички, используют ли они ORM или нет. Им просто нужно увидеть результаты, и если они компетентны, они получат это.

Что мы видели в наших веб-приложениях, так это то, что обычно самые трудные для устранения узких мест в производительности больше не связаны с базой данных, даже с ORM. Скорее, они находятся на переднем крае (в браузере) из-за пропускной способности, AJAX-издержек и т. Д. Даже серверы баз данных среднего уровня в наши дни невероятно мощны.

Конечно, другие магазины, работающие на более крупных системах с высоким спросом, могут иметь другой опыт. :)

Answer 4

Это подробно обсуждалось на предыдущих вопросах.

Каковы плюсы и минусы сохранения SQL в хранимых процессах и кода

Answer 5

Хранимые процедуры руками вниз. ИЛИ Mappers зависят от языка и часто добавляют графические замедления.

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

Мое личное мнение об OR Mappers состоит в том, что их существование подчеркивает недостаток дизайна в популярной структуре баз данных. Разработчики баз данных должны понимать задачи, которые люди пытаются решить с помощью сложных OR-Mappers, и создавать серверные утилиты, которые помогают в выполнении этой задачи.

ИЛИ Mappers также являются эпическими мишенями синдрома «вытекающей абстракции».

Там, где довольно просто найти вещи, с которыми он просто не может справиться, потому что уровень абстракции не является экстрасенсорным.

Answer 6

Определенно ORM . Более гибкий, более переносимый (как правило, они имеют встроенную мобильность). В случае медлительности вы можете использовать кэширование или вручную настроенный SQL в горячих точках.

Обычно хранимые процедуры имеют несколько проблем с ремонтопригодностью.

• отдельно от приложения (так много изменений теперь нужно сделать в двух местах)
• как правило, сложнее изменить
• сложнее поставить под контроль версий
• труднее убедиться, что они обновлены (проблемы развертывания)
• портативность (уже упоминалось)

Answer 7

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

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

Answer 8

«Я пытаюсь вбить гвоздь. Должен ли я использовать каблук своей обуви или стеклянную бутылку?»

И Хранимые процедуры, и ORM сложны и раздражают в использовании для разработчика (хотя и не обязательно для администратора баз данных или архитектора соответственно), поскольку они требуют начальных затрат и более высоких затрат на обслуживание, которые не гарантируют выкл.

Оба хорошо окупятся, если не ожидается, что требования сильно изменятся в течение срока службы системы, но они будут мешать вам, если вы создаете систему, чтобы сначала обнаружить требования.

Простой код SQL или квази-ORM, такие как LINQ и ActiveRecord, лучше подходят для проектов со сборкой для обнаружения (которые происходят на предприятии гораздо чаще, чем PR хочет, чтобы вы думали).

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

Полноценные ORM лучше, если вы делаете Big Design Up Front, используете много UML, хотите абстрагировать серверную часть базы данных, и ваш архитектор лучше понимает требования, чем ваши DBA или программисты.

И есть вариант № 4: использовать их все. Целая система обычно не является одной программой, и хотя многие программы могут взаимодействовать с одной и той же базой данных, каждая из них может использовать любой метод, подходящий как для конкретной задачи программы, так и для ее уровня зрелости. То есть: вы начинаете с прямого кода SQL или LINQ, а затем совершенствуете программу, проводя рефакторинг в ORM и хранимых процедурах, где вы видите, что они имеют смысл.

Answer 9

Ну, SP уже там. Это не имеет смысла, может их действительно. Я думаю, имеет ли смысл использовать картограф с SP?

Answer 10

Если у вас уже есть API данных, представленный в виде sprocs, вам потребуется оправдать капитальный ремонт архитектуры для перехода на ORM.

Для построения зеленых полей я бы оценил несколько вещей:

1. Если в команде есть выделенный администратор базы данных, я бы предпочел sprocs
2. Если более одного приложения касаются одной и той же БД, я склоняюсь к sprocs
3. Если нет возможности перенести базу данных, я бы предпочел sprocs
4. Если я пытаюсь внедрить MVCC в БД, я бы предпочел sprocs
5. Если я разверну это как продукт с потенциально несколькими внутренними базами данных (MySql, MSSql, Oracle), я бы предпочел ORM
6. Если у меня сжатые сроки, я бы предпочел ORM, поскольку это более быстрый способ создания моей модели предметной области и ее синхронизации с моделью данных (с использованием соответствующих инструментов).
7. Если я раскрываю одну и ту же модель домена несколькими способами (веб-приложение, веб-служба, клиент RIA), я склоняюсь к ORM, поскольку модель данных затем скрывается за фасадом ORM, что делает надежную модель домена более ценным для меня.

Я думаю, что производительность - это немного красной селедки; Похоже, что hibernate работает почти так же или лучше, чем SQL, написанный вручную (из-за уровней кэширования), и в любом случае легко написать неверный запрос в sproc.

Наиболее важными критериями, вероятно, являются набор навыков команды и долгосрочные потребности в переносимости базы данных.