Хранимые процедуры - плохая практика в одной из крупнейших в мире консалтинговых фирм по ИТ-программному обеспечению?

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

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

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

135 голосов | спросил 4 revs, 3 users 86%
user673740
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

23 ответа


266

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
150

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

  

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

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

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

  

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

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

  

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

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

  

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

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

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

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

  

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

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

  

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

Неверный вопрос

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

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

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

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

  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
55

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

  

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
44

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

  • Бизнес и прикладная логика должна быть в коде, а не в базе данных. Ввод логики в БД вызывает проблемы.
  • Вы не можете тестировать сохраненные процессы так же легко, как код в ваших обычных тестовых проектах с остальной логикой приложения.
  • Я не нахожу сохраненные procs как способствующие тестированию первого программирования, когда я пишу код.
  • Сохраненные процедуры не так легко отлаживаются, как код приложения, когда вы отлаживаете свою программу в своей среде IDE.
  • Управление версиями /контроль источника SP по сравнению с обычным кодом
ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
20
  

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

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

  

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

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

  

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

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
17

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
16

Все три компании, которые я работаю для использования хранимых процедур для их логики приложений с 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 раз медленнее, чем C, курит 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 в любой день. Таблицы Hash /Связанные списки /Etc. Я возьму фреймворки Java Collection и т. Д. И то же самое для .NET ... И C #, и Java - это еще более развитые языки, чем Transact SQL ... Чек кодирование с Transact-SQL заставляет меня ревновать к C .. .

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

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

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
12

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

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

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
8
  

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

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

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

  

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

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

  

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

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

  

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

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

  

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

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

  

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
4

Для кого вы работаете?

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

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

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

введите описание изображения здесь>> </p>

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
4

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
4

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

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

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

Итак, на стороне con.

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

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

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

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

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

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

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

  3. Повторное использование запроса.

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
2

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
2

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

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

Это не что иное, как программист v конкурс писателей DBA.

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
2

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
2

Это еще один момент, о котором не упоминалось:

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
2

Программирование соло, Я не могу сопротивляться записывать хранимые процедуры.

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
1

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
1

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
0

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

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
-1

Первая

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

Альтернативы

  • Использование фреймворков для отображения реляционных объектов базы данных, для бизнеса объекты (объекты), Hibernate , Entity Framework /LINQ-SQL , вы может иметь строго типизированный доступ к базе данных.

  • Использование кластера QueryItem на уровне доступа к данным для хранения SQL-запросов sentencies

  • Использование XML-файлов для хранения SQL-запросов

Случаи, когда вы не должны использовать SPs

  • Когда предложение sql прост или единственная команда

  • Когда SQL-запрос создается динамически на основе пользовательского ввода. (Также внутри Sp вы можете использовать динамический SQL)

  • Когда вы используете инструмент ER-mapping, потому что хотите изменить базу данных на базу данных, не беспокоясь о диалоговом языке sql.

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
-1

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

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

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

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33
-2

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

Выбирайте свои инструменты с умом, и вы сэкономите мир в больнице в долгосрочной перспективе.

ответил Gherman 22 ndEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 22 Sep 2017 20:03:33 +0300 2017, 20:03:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132