Хранимые процедуры или картографы?

Question

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

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

Или картографы также являются эпическими мишенями синдрома "дырявой абстракции" ( Джоэл О Программном обеспечении:Дырявые Абстракции )

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

Я лично обнаружил, что SP, как правило, работают быстрее с точки зрения производительности, по крайней мере, для больших элементов данных, которые я выполняю на регулярной основе.Но я знаю многих людей, которые клянутся OR tools и не стали бы делать ничего другого.

Answer 9

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

Answer 10

На самом деле они не являются взаимоисключающими, хотя, с вашей точки зрения, обычно так и есть.

Преимущество использования объектно-реляционного сопоставления заключается в том, что вы можете менять источники данных местами.Не только структуру базы данных, но и вы могли бы использовать любой источник данных.С появлением веб-сервисов advent / сервис-ориентированной архитектуры / ESB в более крупной корпорации было бы разумно рассмотреть возможность разделения задач на более высоком уровне, чем то, что вы могли бы получить в хранимых процедурах.Однако в небольших компаниях и в приложениях, которые никогда не будут использовать другой источник данных, SP могут прекрасно подойти.И последнее замечание: нет необходимости использовать картограф OR для получения абстракции.Моя бывшая команда добилась большого успеха, просто использовав модель адаптера с использованием Spring.NET для подключения источника данных.

Answer 11

@ Кент Фредрик

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

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

Answer 12

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

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

Большинство картографов OR могут обращаться к сохраненным процедурам для остальных.

Вы не должны использовать хранимые процедуры, предполагая, что они быстрее, чем оператор sql в строке, это не обязательно имеет место в последних нескольких версиях MS SQL server.

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

Вам не нужно использовать картограф OR, чтобы получить модель домена POCO, но это действительно помогает.

Answer 13

Если у вас уже есть 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 легко написать неверный запрос.

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

Answer 14

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

Answer 15

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

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

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

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

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

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

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