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

Question

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

Answer 1

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

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

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

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

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

Вам не нужно использовать OR mapper для получения модели домена POCO, но это помогает.

Answer 2

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

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

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

Answer 3

Они на самом деле не являются взаимоисключающими, хотя на ваш взгляд они обычно таковы.

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

Answer 4

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

Answer 5

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