Каков аргумент для и против размещения кода в хранимых процедурах с намерением сделать код более пригодным для обслуживания (т.е. упростить внесение изменений в бизнес-правила без перекомпиляции кода)?
Все остальные равны, что делает хранимую процедуру лучше/хуже для обслуживания?
Хранимые процедуры являются плохой практикой по ряду причин.
Одним из наиболее важных является разделение проблем. С хранимыми процедурами у вас есть бизнес-логика в слое данных, а не на уровне обслуживания, где она принадлежит. Одним из следствий этого является то, что теперь у вас есть один язык и один язык, на котором можно реализовать свою бизнес-логику. По мере появления новых технологий у вас нет хорошего пути миграции.
Еще одна веская причина избежать хранимых процедур заключается в том, что хранимые процедуры создают прочную связь между вами и поставщиком БД. Будет очень сложно когда-либо перейти к другому поставщику БД, тогда как ваша бизнес-логика на уровне обслуживания позволит вам очень легко заменить DB. Таким образом, хранимые процедуры обеспечивают большую выгоду для поставщика БД, а не столько для вас.
Далее, масштабируемость. Это довольно просто, чтобы создавать сервисы на среднем уровне и распределять их по кластеру. Как вы собираетесь делать это с помощью хранимой процедуры? Я думаю, что было бы очень сложно сгруппировать хранимую процедуру через, скажем, еще восемь машин.
Далее, интеграция с другими системами. Если ваша система извлекает данные из вашей базы данных, опираясь на хранимые процедуры и другие данные из других систем, эта логика почти наверняка должна быть на уровне служб. Если какая-то ваша бизнес-логика находится на уровне сервиса, а некоторые - на бизнес-уровне, у вас есть что-то вроде проблем обслуживания.
Вероятно, это зависит от вашей системы. Для нас хранимые прокси используются почти исключительно. У нас есть только один веб-сайт, поэтому наличие SQL-запросов в хранимой процедуре делает наш DBA намного проще настраивать запросы и воссоздавать проблемы, вызывающие проблемы.
Подумайте об альтернативах...
Затем рассмотрите свои требования и среду...
Являются ли ваши разработчики знакомыми с вашими инструментами управления базами данных или у вас есть больше программистов баз данных и администраторов, обрабатывающих сторону db тогда забора?
Вам нужно часто вносить изменения в схему db?
Как насчет безопасности? Вам нужна защита до уровня пользователя базы данных? Было бы проще управлять безопасностью в коде или в db?
Могут ли ваши разработчики быть более продуктивными с ORM, не имея необходимости писать DAL для себя или есть ли добавленная сложность, которую вы хотели бы добавить в свой DAL особый способ, который ORM не мог предоставить?
и т.д...
Люди будут придерживаться разных мнений относительно того, легче или проще обрабатывать procs в зависимости от того, какие системы и среды, в которых они работали, которые, вероятно, сильно отличаются от ваших собственных. То, что вы, вероятно, должны делать, а не просто интересно, легче ли им поддерживать, выясняет, соответствуют ли они вашим потребностям. Это действительно хороший вопрос, но, возможно, отредактируйте свой пост и объясните немного больше о вашем env. и вы можете получить немного более целенаправленный совет.
Хранимые процедуры предоставляют много преимуществ по сравнению с тем, чтобы хранить запросы в приложении, и многие уже упоминались.
Хранимые процедуры служат слоем абстракции между приложением и данными, а слои абстракции редко бывают плохими.
Вы можете достичь определенного уровня повторного использования, если у вас есть каскадные операции с базой данных. Например, процедура Delete_Employee может вызывать процедуру Delete_Address в транзакции и делать много других вещей с одним запросом базы данных из приложения.
Слой представлений под хранимыми процедурами может быть использован для изоляции приложения от изменений схемы и настройки производительности запроса/присоединения.
Уровень хранимой процедуры является важной частью надежной архитектуры предприятия и структуры. Эти хранимые процедуры не должны содержать никакой бизнес-логики, конечно, они должны проходить только через данные и не манипулировать им.
Чтобы реализовать эти преимущества, хорошая дисциплина заключается в поддержании согласованности и одинаковой степени детализации во всех процедурах в приложении. Я работал над приложениями с множеством 100 процедур. Если бы все эти запросы были в коде, было бы намного сложнее, если не невозможно, реализовать безопасность на уровне данных. Сохраненные процессы могут быть легко сгенерированы. Я считаю, что общая производительность выше с хранимыми процедурами, чем без. И, конечно же, хранимые процедуры могут быть размещены в исходном управлении, как это имеет место со всеми другими объектами базы данных.
Если ваше базовое программное обеспечение развернуто на нескольких разных клиентских сайтах, большая часть настроек, необходимых для каждого отдельного клиента, может быть выполнена через базу данных (представления и хранимые процедуры). Вы можете почти думать о SP как о INTERFACE, передавать стандартные данные взад и вперед, не заботясь о том, что происходит внутри.
Это, конечно, также можно обрабатывать другими способами, такими как пользовательский .dll уровень данных для каждой установки.
Однако в некоторых случаях настройка в пакете SP вместо DLL позволяет ускорить настройку и позволяет эксперту по DBA или данным взять на себя ответственность, оставив программиста работать над кодированием.
Помните, что код в SP доступен многим другим людям (в данном случае клиенту), чем скомпилированный код. Это может быть хорошим или плохим, в зависимости от вашей ситуации.
На некоторых предприятиях политически проще изменить хранимую процедуру, чем переустанавливать программное обеспечение (что больше зависит от того, кто имеет более строгие правила, разработчиков и менеджеров проектов, администраторов баз данных или ИТ/помощи стол).
Мой опыт заключается в том, что управление источником редко используется так же старательно для поддержки базы данных, как и для кода приложения. Конечно, это, вероятно, не всегда так, но через 15 лет я никогда не видел его. Это означает, что у вас больше шансов, что люди вносят изменения в dev, и небо запрещает жить, база данных хранит проки без реальной мысли, чтобы облегчить обслуживание, потому что это слишком просто.
Я не спорю с хранимыми процедурами, но я бы сказал, что их сложнее поддерживать, поскольку они должны обновляться независимо от обновления приложения (они должны храниться на сервере sql).
Равно, это плохая практика менять "на лету", вы помните?
Серьезно, создание кода в хранимой процедуре может сделать вас уверенным, что взаимодействие с SQL быстрее.
Но ваши изменения слишком далеки от контроля источника. (для контроля источника вам нужно экспортировать, как я знаю)
Я считаю, что основным недостатком, по моему опыту, является то, что немногие разработчики, с которыми я работал, действительно были довольны SQL (написав его, в первую очередь, отлаживая его). Поэтому вы должны убедиться, что у вас будет правильное умение установленный в вашей команде, чтобы иметь возможность поддерживать много SQL.
Большое преимущество может быть, если у вас есть несколько платформ (скажем, как в Windows, так и в веб-приложениях), или вы переносите старое приложение в новую технологию, вы можете повторно использовать процедуры базы данных.
В приложении, с которым я работаю, есть много бизнес-функций в хранимых процедурах, и, вероятно, половина ошибок, которые мы исправляем, содержатся в SQL-коде, и если критический момент можно быстро устранить, заменив хранимую процедуру, в отличие от ошибки в коде приложения, которые должны ждать следующей версии. (обратная сторона хотя заключается в том, что у нас могло быть меньше ошибок в первую очередь, если бы мы не писали столько кода SQL, кто знает!)
Я программировал CRUD в качестве консультанта в течение 10 лет в деловом мире. Я могу сказать вам, что я вкладываю столько логики бизнеса в sprocs и views, сколько могу (и имеет смысл). Требования, как правило, меняются каждый раз, когда ветры дуют, а логика в базе данных облегчает изменение и (с приличными комментариями) сама документирует. Плюс sprocs делают для хорошей безопасности и для легкого повторного использования кода.
FWIW Я использую контроль источника и строгое тестирование на всех моих sprocs. В противном случае это просто ленивость.
Сохраненные процедуры являются хорошей идеей по ряду причин:
Поместив бизнес-логику ближе к данным, вы можете иметь любое количество клиентских интерфейсов для данных. Первоначально вы можете создать интерфейс для веб-сайта, но теперь они хотят получать отчеты. Нет проблем, бизнес-логика рядом с данными. Откройте API, поставьте веб-службу перед процедурой. Вы хотите использовать самый горячий новый язык, идите вперед. Бизнес-логика находится рядом с данными.
Другая причина использования хранимых процедур заключается в том, что она создает прочную связь между вами и выбранной базой данных. Таким образом, вы можете воспользоваться встроенной функциональностью DB, за которую вы платите (или используете в случае с открытым исходным кодом). И угадайте, что, если вы попытаетесь сделать независимым от вашего приложения DB, у вас, вероятно, будет много трудностей для отслеживания ошибок. Простая согласованность работает по-разному в каждой базе данных поставщика.
Вы можете использовать встроенную масштабируемость вашей базы данных (кластер, RAC - однако они реализуют его). Не нужно писать свои собственные.
Труднее написать код, который не использует переменные связывания (мягкие разборки Google и жесткие разборки, если вам нужна дополнительная информация об этом).
Контроль версий - компании, которые я всегда использовал контроль версий для хранимых процедур. Обычно вы записываете хранимые процедуры в каком-то редакторе. Большинство редакторов теперь поддерживают поддержку хотя бы одной из основных систем управления версиями.
Внешний код должен извлекать данные по сети, а затем работать с ним.
Наконец, не все процедурные языки создаются одинаково. MySQL только что выпустил возможность использовать хранимые процедуры, и они дают вам несколько языков, которые вы можете использовать, включая их собственные. Я сомневаюсь, что они встают на сторону Oracle или SQl Server. Я не буду вдаваться в то, кто лучший, потому что я не эксперт ни в чем, кроме Oracle. Oracle PL/SQL обладает множеством функциональных возможностей, которые оптимизированы в ядре БД. Я уверен, что MS SQL делает это тоже, а другие.
Надеюсь, что это полезно (и имеет смысл - длинный день).
в проекте, над которым я работаю, большую часть обслуживания можно выполнить, только изменив процедуры sql. поэтому процедуры "Да" в моем случае более важны, также они имеют лучшую производительность, чем выполнение операторов SQL из вашего кода.
Как правило, этот аргумент создается из-за того, что вы делаете специальные изменения в хранимых процедурах, вместо того, чтобы проходить контроль версий, тестирование и т.д., что скомпилированный код прошел бы.
У меня нет немедленной реакции коленного рефлекса на это (в отличие от большинства людей здесь), но я скажу, что компиляция и развертывание DLL действительно не намного сложнее в этом типе ковбойской среды. Или вы можете использовать что-то вроде CS- Script, что позволяет хранить необработанные файлы .cs, которые компилируются по требованию.
Мне всегда было сложно выполнить версию и протестировать сохраненные procs, тогда как большинство кода легко сделать. Кроме того, большинство процедурных языков РСУБД довольно примитивны, поэтому вы не представляете выразительности или абстракций, которые дает вам современный язык.
Конечно, контроль версий - это хорошая вещь - и, в большинстве случаев, это некоторые проверки процессов между разработчиками и производительностью.;)
Некоторые утверждают, что бизнес-логика не имеет места в хранимых процедурах и приводит к недостижимым системам. Я хотел бы указать, что эти аргументы в основном связаны с точками зрения DDD и N-Tier, которые стремятся разместить всю бизнес-логику в определенном регионе на прикладном уровне. Хотя это достойная цель, есть и другие точки зрения, которые стоит рассмотреть. SP также могут сделать намного больше, чем просто бизнес-логику.
Кстати, мир Oracle считает своей лучшей практикой иметь всю бизнес-логику в коде PL/SQL в БД, и они кое-что знают о реляционных базах данных!
Рассмотрим эти применения SP:
Производительность.. Часто бывает полезно запускать несколько операторов SQL в SP и тем самым избегать того, чтобы ваше приложение совершало многократные поездки в DB, что приводило к значительным улучшениям производительности.
Управление изменениями.. SP просто просты в обслуживании и изменении, если у вас есть дисциплина вокруг контроля версий и процесса развертывания.
SP могут быть выпущены в живые производственные системы без сбоев, что может быть значительным преимуществом в 24/7 операциях. Конечно, вам все равно нужно жестко контролировать процесс выпуска.
Уровень абстракции. SP могут абстрагировать детали схемы БД из приложения, при условии, что все взаимодействия с приложением /db осуществляются через SP. Это может быть очень мощная концепция. Считайте, что продолжительность жизни БД часто переживает приложение - приложения приходят и уходят и переписываются каждый раз с использованием новейших технологий и шаблонов архитектуры, но ценные данные остаются в одной старой реляционной БД для эонов. Зачастую приложения с несколькими файлами разрабатываются на одной и той же БД, даже если это никогда не было первоначальным намерением. SP в этих сценариях используются для обеспечения плотного, хорошо определенного API между приложением и БД, который можно тщательно контролировать, чтобы обеспечить согласованное взаимодействие с несколькими приложениями и даже с несколькими версиями одного и того же приложения.
Это разделение проблем между схемой db и приложением оставляет программистов приложений свободными делать то, что они делают лучше всего, оставляя DBA свободной рукой для улучшения схемы с течением времени, не нарушая приложения.
Независимо от используемого шаблона архитектуры, SP могут играть ценную роль. Не управляйте тогда из любого дизайна и, как любой инструмент, используйте его там, где это имеет смысл.
Я еще об управлении версиями. На моей последней работе я добавил сторонний пакет, который запускался каждый день и сохранял копию каждого объекта DDL или кода, если он изменился с момента последнего резервного копирования. Он сам был хранимыми процедурами, поэтому их можно было запустить вручную или с помощью триггера, как бы вы хотели его запустить. Это само по себе является системой контроля версий.
Это был довольно хороший инструмент и стоил всего около 200 долларов. Он даже пришел с инструментом diff, чтобы показать вам, что изменилось.
Мы перешли от использования sprocs к сгенерированному DAL для бизнес-логики на основе кода по нескольким причинам:
Это действительно зависит от того, насколько хорошо хранятся хранимые процедуры, не так ли? T-SQL и PL-SQL могут быть столь же грубыми и жесткими, как С# или COBOL, если практик не кодирует некоторые мысли и заботы.
В одном из последних улучшений, над которым я работал, я намеренно добавлял функциональность в хранимый процесс, главным образом потому, что мне хотелось, чтобы функциональность была проще справляться, а тем более поддерживать (хранимая процедура может быть вызвана с уровня БД, а также на уровне клиента, если бы я поместил логику в другой слой, это было бы неверно). Я думал, что неплохо сделал PL-SQL довольно модульным, но когда TOAD проанализировал его, 3 из 4 разделов получили хорошие оценки, а последний был забит для высокой циклической сложности. Хех, я думаю, что я только что доказал свою точку зрения.
Я думаю, что одним из факторов, влияющих на это, является количество клиентов, так как это позволяет делать изменения схемы без необходимости повторного развертывания приложений. Например. как DBA, я нахожу это намного проще при настройке SQL, разрешении ошибок и т.д., чтобы посетить один хранимый Proc, а не X-клиенты, чтобы изменить инструкцию SQL, когда X - большое число, а "посещение" означает развертывание новой версии приложения на несколько рабочих станций.
Выполнено правильно, это также означает, что схема, используемая приложением, может отличаться от схемы хранения данных. Например. Я очень хочу нормализовать схему данных и предоставить набор представлений и хранимых процедур, которые использует приложение. Схема приложений изменяется со временем с изменениями кода приложения и не зависит от схемы данных. Это реальное преимущество в системах с несколькими приложениями (например, одно приложение для чтения и записи и приложение для веб-сайта, использующее одни и те же данные.)
Часто существует другой набор инструментов и другой язык, используемый для записи хранимых процедур. Это может быть препятствием для удовлетворения потребностей в обучении, развитии навыков и т.д.
Я предпочитаю не использовать хранимые процедуры, потому что мне нравится оставаться агностиком базы данных. Если появится лучшая реляционная база данных, я бы хотел иметь возможность перейти на нее. Хранимые процедуры заблокируют вас. Тем не менее, я иногда использую их, они могут быть очень мощными.