Хранимая процедура SQL Server против внешней библиотеки DLL

Question

Я пытаюсь убедить кого-то, что использовать внешнюю DLL для управления данными sql лучше, чем использовать хранимые процедуры. В настоящее время человек, с которым я работаю, использует vba и вызывает хранимые процедуры sql для получения необходимых сложных данных из разных источников. Насколько я понимаю, лучший способ сделать это - использовать dll / некоторый промежуточный уровень для получения данных и возможности их форматирования в соответствии с потребностями.

Некоторые вещи, которые следует иметь в виду:

• Человек, с которым я работаю, мало заботится о возможности масштабирования гораздо дальше, чем мы сейчас
• Они не хотят переключаться на разные платформы
• Они не видят большой проблемы с производительностью при текущей настройке
• Использование DLL требует больше работы в другом направлении
• Они не хотят переключаться, если в настоящее время нет проблемы с тем, чтобы сделать это так, как сейчас (просто потому, что это не правильный путь, не будет работать ... Я пытался)

Так может ли кто-нибудь сказать мне некоторые преимущества использования внешней библиотеки DLL, а затем использования хранимых процедур SQL?

Answer 1

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

Этот тип дизайна в основном настолько стандартизирован, и вот уже много лет, как Microsoft включила платформу, которая создает его для вас в .NET 4.

Более или менее, и вы, и этот другой человек правы, используйте sprocs для обеспечения безопасности и отделите свой DAL для обеспечения безопасности и возможности повторного использования и по многим причинам

Answer 2

ORM / DLL подход

Pro:

• Вам не нужно изучать SQL или синтаксис хранимой процедуры

Con:

• Сложно несколько операций в одной транзакции
• Риск увеличения числа обращений между приложением и базой данных, что означает проблемы с синхронизацией данных / параллелизмом
• Совершенно терпит неудачу при сложных запросах; большинство поддерживает хранимые процедуры через ORM из-за этого

Вы можете сохранять SQL, включая хранимые процедуры, в виде простых файлов. Расширение файла может быть txt, но большинство использует sql - делает хранение исходного кода SQL в CVS / etc спорным против исходного кода .NET или Java.

Answer 3

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

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

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

Answer 4

Я действительно думаю, что все сводится к вопросу предпочтения . Лично мне нравится ORM и сохраненные запросы в DLL по сравнению с сохраненными процессами, я считаю, что их гораздо проще поддерживать и распространять, чем развертывать S.Procs в БД. Хотя у S.Proc есть некоторые определенные преимущества перед необработанным запросом. Некоторые оптимизации и некоторая логика на стороне сервера, которая может повысить производительность в некоторых областях.

В целом, хотя лично я предпочитаю работать в коде, а не в БД mumbo-jumbo, так что именно поэтому я выбираю подход DLL.

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

Просто мой 2с.