Маленькие методы - маленькие sprocs

Question

Дядя Боб рекомендует иметь небольшие методы. Имеют ли хранимые процедуры идеальный размер? Или они могут работать на 100 и 100 строк?

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

Если вы читаете Adam Machanic, его предвзятость относится к базе данных, значит, это подразумевает длительные хранимые процедуры, которые понимает только автор sproc, оставляя сопровождающих иметь дело с беспорядком?

Я думаю, что есть два взаимосвязанных вопроса.

Заранее благодарим за ответ на нечеткий вопрос (ы).

Answer 1

Я бы применил те же рекомендации к SP как можно больше, поскольку я рассматриваю код SP.

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

Я сомневаюсь, что Адам Мачаник или большинство из них будут выступать за то, что длинные SP, которые трудно понять и поддерживать, - это хорошо.

Answer 2

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

Answer 3

Я думаю, что хранимые процедуры в настоящее время НИКОГДА не должны использоваться для всей системы как единственный метод доступа к базе данных. Это устаревшая архитектура, которая в долгосрочной перспективе дает гораздо больше проблем с обслуживанием, чем преимущества. В настоящее время существует много лучших способов обработки каждого требования к доступу к данным. Лучшее использование хранимой процедуры для некоторых редких случаев, когда вы хотите, чтобы одна, четко определенная и уникальная функция извлекала данные, которые, как вы знаете, будут использоваться таким же образом другими приложениями. Хранимая процедура позволит вам быть СУХОЙ в этом случае. Также в некоторых случаях, когда ваш администратор db, который обрабатывает систему безопасности, должен защищать определенную часть данных (например, таблицу кредитных карт) таким гранулированным способом, чтобы обеспечить доступ только к SP - это хороший вариант.

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

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