Я работаю над проектом в одной из трех ведущих мировых консалтинговых фирм, и администратор БД сказал мне, что хранимые процедуры лучших практик компании не являются «лучшей практикой». Это так противоречит всему, что я узнал.

Хранимые процедуры обеспечивают повторное использование кода и инкапсуляцию (два столпа разработки программного обеспечения), безопасность (вы можете предоставлять / отзывать разрешения для отдельного хранимого процесса), защищать вас от атак с использованием SQL-инъекций, а также помогают с быстротой (хотя администратор базы данных сказал, что начиная с SQL Server 2008, даже если обычные запросы SQL компилируются, если они выполняются достаточно много раз).

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

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

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

Некоторые наблюдения

Хранимые процедуры обеспечивают повторное использование кода и инкапсуляцию (два столпа разработки программного обеспечения),

Только если вы используете их правильно в контексте, в котором они должны использоваться. То же самое можно сказать о функциях (в структурном программировании) или методах (в объектно-ориентированном программировании), и все же мы видим 1K-функции и объекты с мега-задницей.

Артефакты не дают вам этих преимуществ. Правильное использование этих артефактов - вот что дает эти преимущества.

безопасность (вы можете предоставлять / отзывать разрешения для отдельного хранимого процесса),

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

защитить вас от атак SQL-инъекций,

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

а также помочь с быстротой (хотя тот администратор базы данных сказал, что начиная с SQL Server 2008 даже обычные запросы SQL компилируются, если они выполняются достаточно много раз).

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

Хороший пример - это запрос данных во временный курсор (или курсоры), из которого запускается другой SQL. Вы можете сделать это программно на сервере приложений или сохранить несколько циклов, выполнив это в БД.

Однако это не должно быть нормой. Если у вас много таких случаев, то это признак плохого дизайна базы данных (или вы извлекаете данные из несовместимых схем баз данных по отделам).

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

Гибкость связана с процессами разработки программного обеспечения и управления требованиями, а не с технологиями.

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

Неправильный вопрос

Вопрос неправильный и эквивалентен вопросу "есть ли веские причины не использовать GOTO"? Я поддерживаю Никлауса Вирта больше, чем Дейкстры в этом вопросе. Я могу понять, откуда пришло мнение Дейкстры, но я не верю, что оно применимо на 100% во всех случаях. То же самое с магазинными процессами и любыми технологиями.

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

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

Другими словами, это отговорка или заявление о невежестве.

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

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

Что делать в вашем случае?

Мой опыт, когда в Риме, делай, как римляне .

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

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

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

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

Мое мнение о том, как их не использовать

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

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

• Не делайте базы данных единственным местом, где хранятся данные вашего магазина. Ваш магазин должен обрабатываться так же, как вы обращаетесь с исходным кодом C # или Java. То есть, источник контроля текстового определения вашего магазина Procs. Люди разглагольствуют, что магазинные прокы не могут контролироваться из-за источника - bullcrap, они просто не знают, о каком чертовом аде они говорят.

Мое мнение о том, как / где их использовать

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

• Тонкий контроль доступа зерна. Вы не хотите, чтобы какой-то идиот запускал декартовы объединения в вашей базе данных, но вы не можете просто запретить людям выполнять произвольные операторы SQL, как это тоже. Типичное решение - разрешить произвольные операторы SQL в средах разработки и UAT, а также запретить их в системных и производственных средах. Любое утверждение, которое должно быть сделано для систематизации или производства, попадает в процедуру магазина, проверенную кодом как разработчиками, так и dbas.

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

• В таких системах, как Oracle, вы можете получить доступ к LDAP или создать символические ссылки на внешние базы данных (скажем, вызвать процедуру магазина на базе данных делового партнера через vpn.) Простой способ создания спагетти-кода, но это верно для всех парадигм программирования, а иногда у вас есть конкретные требования бизнеса / среды, для которых это единственное решение. Процедуры Store помогают инкапсулировать эту злобность в одном месте, рядом с данными и без необходимости проходить к серверу приложений.

Выполните ли вы это на БД в качестве магазина или на сервере приложений, зависит от компромиссного анализа, который вы, как инженер, должны сделать. Оба варианта должны быть проанализированы и обоснованы с помощью определенного типа анализа. Идти тем или иным способом, просто обвиняя другую альтернативу как «плохую практику», это просто неудачный инженерный отбой.

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

Становится ли это постоянным решением или нет, это зависит от ограничений, наблюдаемых в данный конкретный момент.

Надеюсь, это поможет.

Смысл в том, что использование слоя хранимых процедур ограничивает переносимость и связывает вас с определенной БД. Дополнительные расходы на техническое обслуживание также приводятся в качестве причины. Я также хотел прокомментировать то, что вы высказали:

(хранимые процедуры) защитят вас от атак SQL-инъекций

Это на самом деле параметризованный запрос защищает вас, что вы можете легко сделать в виде простого SQL-запроса.

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

• Бизнес и логика приложения должны быть в коде, а не в базе данных. Помещение логики в БД смешивает проблемы.
• Вы не можете тестировать хранимые процессы так же легко, как код в ваших обычных проектах модульного тестирования с остальной логикой приложения.
• Я не нахожу хранимые процедуры как способ тестирования первого программирования, когда я пишу код.
• Хранимые процедуры не так легко отлаживать, как код приложения, когда вы отлаживаете свою программу в IDE.
• Контроль версий / Контроль версий SP и нормального кода

Хранимые процедуры обеспечивают повторное использование кода и инкапсуляцию (два столпа разработки программного обеспечения),

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

защитить вас от атак SQL-инъекций,

Нет, они не Я даже не могу догадаться, откуда могла прийти эта идея, как я часто слышал, и это просто неправда. Это может смягчить некоторые типы атак SQL-инъекций, но если вы не используете параметризованные запросы, это не имеет значения. Я все еще могу '; DROP TABLE счета; -

а также помочь с быстротой (хотя тот администратор базы данных сказал, что начиная с SQL Server 2008 даже обычные запросы SQL компилируются, если они выполняются достаточно много раз).

Они также обычно компилируются, когда вы используете подготовленные параметризованные операторы (по крайней мере, с несколькими из используемых мной БД). К тому времени, ваше приложение начинает выполнение запроса (или особенно при выполнении тех же подготовленный запрос нескольких раз), любое преимущество в производительности, что вы думаете, что ваш SP имеет совершенно спорно.

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

Слушай своего администратора. Он знает, что случилось.

Это была официальная линия, когда я работал на одну из Большой Пятерки несколько лет назад. Обоснованием было то, что поскольку SP привязаны к конкретным реализациям (PL / SQL против T / SQL против ...), они излишне ограничивают выбор технологий.

Пережив миграцию одной большой системы из T / SQL в PL / SQL, я могу понять этот аргумент. Я думаю, что это немного неестественно - сколько мест действительно перемещается из одной базы данных в другую по прихоти?

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

Допустим, у вас есть хранимая процедура, которая возвращает набор данных, который вы хотите использовать, как вы можете использовать его в будущих хранимых процедурах? Механизмы на SQL Server для этого не очень хороши. EXEC INTO ... работает только на один или два уровня вложенности (я забыл сейчас). Или вы должны предварительно определить рабочую таблицу и настроить ее обработку. Или вам нужно предварительно создать временную таблицу и заполнить ее процедурой. Но что, если два человека называют временную таблицу одним и тем же в двух разных процедурах, которые они никогда не планировали использовать одновременно? На любом обычном языке программирования вы можете просто вернуть массив из функции или указать на объект / глобальную структуру, совместно используемую между ними (за исключением функциональных языков, где вы должны вернуть структуру данных, а не просто изменить глобальную структуру ... )

Как насчет повторного использования кода? Если вы начнете помещать общие выражения в UDF (или, что еще хуже, в подзапросы), вы замедляете выполнение кода. Вы не можете вызвать хранимую процедуру, чтобы выполнить вычисление для столбца (если только вы не используете курсор, передайте значения столбца одно за другим, а затем каким-то образом обновите свой набор таблиц / данных). Таким образом, чтобы получить максимальную производительность, вам нужно вырезать / вставлять общие выражения повсеместно, что является кошмаром обслуживания ... С помощью языка программирования вы можете создать функцию для генерации общего SQL, а затем вызывать ее из любого места при сборке. строка SQL. Тогда, если вам нужно изменить формулу, вы можете внести изменения в одном месте ...

Как насчет обработки ошибок? SQL Server имеет много ошибок, которые немедленно останавливают выполнение хранимой процедуры, а некоторые даже приводят к отключению. С 2005 года есть try / catch, но все еще есть ряд ошибок, которые не могут быть обнаружены. Также происходит то же самое с дублированием кода в коде обработки ошибок, и вы действительно не можете передавать исключения так же легко, как это происходит с большинством языков программирования .....

Также просто скорость. Многие операции над наборами данных не ориентированы на SET. Если вы попытаетесь сделать что-то ориентированное на строки, вы либо будете использовать курсор, либо вы будете использовать «курсор» (когда разработчики часто запрашивают каждую строку одну за другой и сохраняют содержимое в переменные @ точно так же, как курсор. ..Даже это часто медленнее, чем курсор FORWARD_ONLY). С SQL Server 2000 у меня было что-то, что работало в течение 1 часа, прежде чем я убил это. Я переписал этот код на Perl, и он закончился через 20 минут. Когда язык сценариев, который в 20-80 раз медленнее, чем С, курит производительность SQL, у вас точно не будет бизнес-написания операций, ориентированных на строки, в SQL.

Теперь SQL Server имеет интеграцию с CLR, и многие из этих проблем исчезают, если вы используете хранимые процедуры CLR. Но многие администраторы баз данных не знают, как писать .NET-программы или отключать CLR из-за проблем безопасности и придерживаются Transact SQL .... Также даже с CLR у вас все еще остаются проблемы совместного использования данных между несколькими процедурами эффективным способом. ,

Кроме того, в общем, сложнее всего масштабировать базу данных. Если вся ваша бизнес-логика находится в базе данных, то когда база данных станет слишком медленной, у вас возникнут проблемы. Если у вас есть бизнес-уровень, вы можете просто добавить больше кэширования и больше бизнес-серверов для повышения производительности. Традиционно другой сервер для установки Windows / Linux и запуска .NET / Java гораздо дешевле, чем покупка другого сервера базы данных и лицензирование большего количества SQL Server. SQL Server теперь имеет большую поддержку кластеризации, хотя изначально у него не было никакой поддержки. Поэтому, если у вас много денег, вы можете добавить кластеризацию или даже сделать доставку журналов, чтобы сделать несколько копий только для чтения. Но в целом это будет стоить намного больше, чем просто кеширование с записью или что-то в этом роде.

Также посмотрите на средства Transact-SQL. Манипулирование строкой? Я возьму классы Java String Class / Tokenizer / Scanner / Regex в любой день. Хеш-таблицы / связанные списки / и т.д. Я возьму фреймворки Java Collection и т. Д. ... И то же самое для .NET ... И C #, и Java гораздо более развитые языки, чем Transact SQL ... Хек-кодирование с Transact-SQL заставляет меня ревновать к C ... ,

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

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

Аргумент SQL-инъекций больше не применяется, поскольку у нас есть параметризованные запросы на стороне языка программирования. Кроме того, даже раньше, чем параметризованные запросы, небольшая замена ("'", "' '") также работала большую часть времени (хотя есть еще приемы, позволяющие пройти через конец строки, чтобы получить то, что вы хотите).

В целом, я думаю, что SQL и Transact SQL - отличные языки для запроса / обновления данных. Но для кодирования любого типа логики, выполнения строковых манипуляций (или манипуляций с чертовым файлом ... вы удивитесь тому, что вы можете сделать с помощью xp_cmdshell ....), пожалуйста, нет. Я надеюсь найти будущее место, где в основном не используются хранимые процедуры. С точки зрения ремонтопригодности кода это кошмар. Кроме того, что произойдет, если вы захотите сменить платформу (хотя на самом деле, если вы заплатили за Oracle / DB2 / Sybase / Sql Server / и т. Д., Вы также можете получить от них все, что можете, используя каждое проприетарное расширение, которое вам поможет. ..).

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

Как вы версии хранимых процедур на сервере?

Если вы передислоцируете хранимые процедуры на сервер из системы управления версиями, вы уничтожаете сохраненный план выполнения.

Хранимые процедуры не должны быть модифицируемыми непосредственно на сервере, иначе как вы узнаете, что действительно работает _ прямо сейчас? Если это не так, инструменту развертывания необходим доступ для записи хранимых процедур в базу данных. Вам придется развертываться в каждой сборке (план exec может отличаться)

Хотя хранимые процедуры не являются переносимыми, в целом SQL тоже не работает (когда-либо встречалась обработка дат оракулом - uggghhh).

Итак, если вы хотите переносимости, создайте внутренний API доступа к данным. Вы можете вызывать это как вызовы функций, и внутренне вы можете встроить в любой язык, который вы хотите, с параметризованными запросами, и это может быть управляемым версией.

Это так противоречит всему, что я узнал.

Вам может понадобиться больше. [ухмыляясь] Серьезно, хранимые процы были в упадке как минимум 10 лет. Практически с тех пор n-ярус заменил клиент-сервер. Снижение было только ускорено принятием ОО-языков, таких как Java, C #, Python и т. Д.

Нельзя сказать, что у хранимых процедур все еще нет своих сторонников и сторонников - но это длительная дискуссия и дебаты. Это не ново и, скорее всего, будет продолжаться довольно долго; ИМО, противники хранимых проков явно выигрывают.

Хранимые процедуры обеспечивают повторное использование кода и инкапсуляцию (два столпа разработки программного обеспечения).

Очень верно. Но, так же как и прилично спроектированный слой OO.

безопасность (вы можете предоставлять / отзывать разрешения для отдельного хранимого процесса)

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

защитить вас от атак SQL-инъекций

Не более, чем выполнение параметризованных запросов. Что вы должны делать в любом случае.

а также помочь с быстротой (хотя тот администратор базы данных сказал, что начиная с SQL Server 2008 даже обычные запросы SQL компилируются, если они выполняются достаточно много раз).

Я думаю, что это началось в MSSQL 7 или 2000. Было много споров, измерений и дезинформации о производительности хранимых процедур и встроенного SQL - я все это делаю под YAGNI. И, если вам это нужно, проверьте.

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

Я не могу придумать много причин, по которым вы хотели бы. Java / C # / любой третий язык GL гораздо более способны, чем T-SQL, к инкапсуляции, повторному использованию, гибкости и т. Д. Большинство из них бесплатны при половинном приличном ORM.

Кроме того, учитывая рекомендации «распространять по мере необходимости, но не больше» - я думаю, что бремя доказывания в наши дни лежит на сторонниках СП. Распространенная причина для того, чтобы загружать хранимые процессы, заключается в том, что T-SQL проще, чем OO, и в магазине есть лучшие разработчики T-SQL, чем OO. Или, что администратор базы данных останавливается на уровне базы данных, а хранимые процедуры являются интерфейсом между dev и администратором базы данных. Или вы отправляете полу-пользовательский продукт, а сохраненные процедуры могут быть настроены пользователем. Если не принимать во внимание некоторые подобные соображения, я думаю, что по умолчанию для любого проекта Agile SW в эти дни будет ORM.

Учитывая все вышеперечисленные случаи, я хотел бы добавить еще один. Выбор ИП может зависеть и от выбора людей.

Я лично чувствую разочарование, когда люди помещают очень сложную логику в SP, и я считаю, что такой SP очень сложен в обслуживании и отладке. Даже во многих случаях разработчик сам сталкивается с проблемой, когда отладка кода (скажем, языковой части) намного проще, чем в SP.

SP следует использовать только для простых операций. Ну, это мой выбор.

Я хочу охватить как некоторые проблемы, так и проблемы с сохраненными процессами. Мы широко используем их в LedgerSMB , и наше правило с несколькими весьма специфическими расширениями гласит: «если это запрос, сделайте его хранимым процессом».

Нашей причиной для этого было облегчить повторное использование многоязычных запросов. Нет лучшего способа сделать это честно.

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

Так что на сторону мошенников.

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

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

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

Вышесказанное довольно сложно отрицать. Они случаются У всех, pro-SP и anti-SP, наверняка были страшные истории об этом. Проблемы не являются неразрешимыми, но если вы не обращаете на них внимания, вы не можете их решить (в LedgerSMB мы используем локатор служб для динамического создания вызовов SP во время выполнения, полностью избегая вышеуказанных проблем. Пока мы являемся PostgreSQL только что-то подобное можно сделать для других БД).

На позитиве. Предполагая, что вы можете решить вышеуказанные проблемы, вы получите:

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

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

3. Запрос повторно.

Да, и несколько вещей, которые вы почти никогда не должны делать в SP:

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

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

На кого вы работаете?

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

В этом конкретном случае приложения приходят и уходят, но очень часто корпоративная база данных живет вечно. Одна из основных функций, которые выполняет СУБД, - предотвращать попадание нежелательных данных в базу данных. Это может включать хранимые процедуры. Если логика является хорошей логикой и вряд ли изменится из года в год, почему она не должна быть в базе данных, сохраняя ее внутренне непротиворечивой, независимо от того, какое приложение написано для использования базы данных? Спустя годы у кого-то возникнет вопрос, который он хочет задать базе данных, и он будет нести ответственность, если нежелательная почта не сможет войти в БД.

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

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

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

У вашей команды тоже нет администратора базы данных, и никто другой не хочет иметь ничего общего с sql.

Это не что иное, как конкурс «Программист против писателя».

ИМО это зависит. Хранимые процедуры имеют свое место, но они не являются лучшей практикой, и их не следует избегать любой ценой. Умный разработчик знает, как правильно оценить данную ситуацию и определить, является ли хранимая процедура ответом. Лично я являюсь поклонником использования ORM некоторого вида (даже базового, такого как raw Linq to Sql), а не хранимых процедур, за исключением, может быть, для предварительно определенных отчетов или аналогичных, но опять же, это действительно на индивидуальной основе.

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

Тем не менее, я знаю компании, которые добиваются больших успехов, помещая всю бизнес-логику в пакеты PL / SQL, живущие в базе данных. Это не очень большие приложения, но тоже не тривиальные; скажем, 20K-100K LOC. (PL / SQL лучше подходит для такой системы, чем T-SQL, поэтому, если вы знаете только T-SQL, вы, вероятно, покачали головой в недоумении ...)

Это еще один момент, еще не упомянутый:

Инструменты генерации кода и инструменты обратного инжиниринга не могут хорошо справляться с хранимыми процедурами. Инструмент обычно не может сказать, что делает proc. Возвращает ли proc набор результатов? Несколько наборов результатов? Получает ли он свои наборы результатов из нескольких таблиц и временных таблиц? Является ли proc просто инкапсулированным оператором update и ничего не возвращает? Возвращает ли он набор результатов, возвращаемое значение и некоторый «консольный вывод»?

Поэтому, если вы хотите использовать инструмент для автоматического создания объекта DTO и слоя DAO объекта передачи данных (как это делает «построитель сервисов»), вы не сможете легко это сделать.

Более того, ORM, такие как Hibernate, не могут работать должным образом, когда источником данных является SP. Доступ к данным в лучшем случае только для чтения.

Программируя в одиночку, я не могу удержаться от написания хранимых процедур.

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

Итак, у меня есть процедура называется logIn. Когда вы входите в систему, вы всегда просто проходите usernameи password. Возвращенный результат - целое число userId.

Когда logInэто хранимая процедура, теперь я могу добавить дополнительную работу, которая должна быть выполнена при входе в систему, которая происходит одновременно с первоначальным входом в систему. Я считаю, что последовательность операторов SQL со встроенной логикой в ​​хранимой процедуре легче написать, чем (вызов окружение FETCH) -> (получить результат) -> (вызывая окружение FETCH) серии, которые вы должны выполнить, когда будете писать свою логическую серверную часть.

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

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

Тем не менее, мы используем SP в моем текущем проекте. Причина в том, что мы создаем новые приложения поверх существующей базы данных, которая все еще поддерживает устаревшие приложения. В результате вносить изменения в схему очень сложно, пока мы не отключим устаревшие приложения. Мы приняли сознательное решение спроектировать наши новые приложения на основе поведения и правил, требуемых для приложения, и использовать SP для временного взаимодействия с базой данных так, как нам хотелось бы, и позволить SP адаптироваться к существующему SQL. , Это относится к предыдущему постеру о том, что SP упрощают внесение изменений на уровне базы данных, не требуя изменений в коде приложения. Использование SP в качестве реализации шаблона адаптера, безусловно, имеет смысл для меня (особенно учитывая мой текущий проект),

Кстати, мы намерены удалить SP при обновлении схемы. Но, как и все остальное в корпоративном развитии, посмотрим, случится ли это когда-нибудь! [Гринь]

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

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

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

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

Хранимые процедуры «для меня» подходят для OLAP «только для чтения», редко используются.

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

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

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

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