Действительно ли использование хранимых процедур является плохой практикой?

Процедуры хранения, как правило, полезны:

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

Еще одним большим преимуществом хранимых процедур является то, что вы можете вносить изменения на бэкэнде «на лету», не требуя повторного развертывания приложения (пока прототип не меняется).

На В большой компании, в которой я работаю, развертывание кода - это ГЛАВНОЕ упражнение, требующее не менее 30 дней и нескольких согласований. Изменения в БД можно сделать почти сразу.

Наконец, помните, что хранимые процедуры также могут обеспечивать защиту от плохих программистов. У вас есть отличный администратор баз данных, но есть команда подрядчиков с самыми низкими ценами, которые пишут ваш код? Администратор базы данных может писать хранимые процедуры, а затем удалять разрешения DML из таблиц, заставляя код проходить хранимую процедуру для внесения каких-либо изменений. Таким образом, вы не

Я работал над проектами, в которых много использовались хранимые процедуры. По сути, бизнес-уровень был перемещен в базу данных, потому что руководитель группы был впечатлен каким-то гуру оракулов, которого он встретил на своей предыдущей работе.

Код хранимой процедуры сложнее поддерживать, чем C # (в Visual Studio), поскольку инструменты хуже, отладка сложнее и т. д.

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

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

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

Любой запрос, который может быть динамическим, не должен быть SP. Если это что-то, что часто меняется, или что-то, к чему вам нужен быстрый доступ, создавать SP - плохая идея. Вот почему. Допустим, вы создали хороший SP, который получает данные определенного типа. У вас есть 3 разных проекта, которые его используют. Но вам нужно что-то немного другое, поэтому ваш выбор:

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

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

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

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

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

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

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

В остальном я скептик. Мне нравится иметь все в одном месте, на языке, на котором я могу выполнить модульное тестирование.

На этот счет есть 2 точки зрения, одни говорят, что они злые, другие клянутся ими. Я смотрю на это посередине дороги.

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

Минусы
Без документации и стандартов все может быстро выйти из-под контроля и превратить обслуживание базы данных в кошмар.

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

Я считаю, что SP хорош для вычислений / обработки данных / источников данных отчетов в БД.

При использовании его исключительно для извлечения данных / обновления строк таблицы вы столкнетесь с целым миром

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

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

Нельзя сказать, что это хорошо или плохо. У них есть преимущества и недостатки, и, в зависимости от проекта, их вес может отличаться.

Некоторые преимущества:

• Они выполняются непосредственно СУБД, поэтому нет необходимости в промежуточной передаче данных на средний уровень в случае множественных запросов. вовлечена (сложная логика).
• Позволяет иметь единственный уровень изменения данных в базе данных.

Некоторые недостатки:

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