sql хранимая процедура против кода, какой из них лучше?

Question

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

1. Должен ли я держать весь код вычисления/Доступ к данным в файле класса (модель), который будет использовать EDM для доступа к данным. Полученные данные до EDM будут уточнены по коду, доступному в файле MODEL, и доступу через контроллер. В этом подходе мне придется создать только несколько моделей, модели отдыха будут созданы EDM и могут быть привязаны непосредственно к Views.

2. Должен ли я держать весь код вычисления/Доступ к данным в хранимой процедуре, который будет использовать SQL-запросов для доступа к данным. Эти доступные данные через SQL-запросы в хранимой процедуре будут использоваться непосредственно по коду, доступному в файле MODEL, и доступу через контроллер. В этом подходе мне нужно будет создать множество моделей, так как мне нужно будет установить параметры процедуры STORED.

Здесь возникает вопрос,

• , какой подход лучше всего подходит для клиента, первый или второй? и почему ?

• Будет ли разница в производительности между этими двумя подходами? Как?

• Какой подход будет реализован быстрее?

• Какой подход безопаснее?

Благодарим вас, заблаговременно.

Answer 1

Что лучше всего для клиента? Давайте ответим на это последним.

Производительность:

Короткий ответ, что он не будет иметь разницу в производительности. В прошлых версиях SQL механизм запросов оптимизировал бы хранимые процедуры, но не специальные запросы. Текущие версии SQL не делают различия. SQL хранит каждый план выполнения до тех пор, пока он может (хранится proc или нет) и будет повторно использовать его, если это возможно. Pro tip - попробуйте не делать свои предложения слишком сумасшедшими, и SQL может использовать его проще. Иногда лучше написать несколько простых запросов, чем написать один большой мега-запрос. Но это БОЛЬШАЯ тема с множеством факторов!

Faster Реализация:

Это легко.Я делал оба метода в течение последних 12 лет, и, без сомнения, писать хранимые процедуры МНОГО более трудоемко. Это также может привести к многочисленным ошибкам, поскольку это еще один слой для няни. Я бы сэкономил 10% от цитаты, если бы клиент позволил мне избежать хранимых процедур. Но многие клиенты настаивают, чтобы я их использовал.

, что приводит нас к ... Безопаснее:

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

Это различие имело вес со мной, покупайте после десятков проектов в десятках компаний, которые мне просто не нужны, чтобы сделать это тонкое различие. Если вас взломали, и у них есть прямой доступ к вашему SQL, а также ваше имя пользователя и пароль, то этот уровень разницы в правах не является проблемой.

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

Answer 2

В то время как модульное тестирование может быть выполнено на procs (обычно с надстройками в БД), я еще не работал в месте, которое выполняет модульное тестирование на procs. Большинство администраторов баз данных я знаю ненасытные дополнения к базе данных. Это также поднимает точку контроля источника. Хотя надстройки для контроля версий существуют, в большинстве случаев этого делать не приходится. Поэтому контроль источника становится немного более болезненным, чем «нормальный» код. Это неплохо, но это, как правило, не так сложно.

Я думаю, что ORM действительно облегчили жизнь для кодеров, чтобы вывести sql из proc и (надеюсь) веб-службы. Одним из преимуществ использования веб-службы для получения ваших данных является абстракция от вашей БД (теперь она может поддерживать несколько БД для вашего продукта) и кэшировать данные, которые не сильно меняются. Это приводит к увеличению производительности HUGE и более предсказуемому доступу к DB, которому нравится DBA!