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

148

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

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

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

user673740
источник
3
Какой код повторного использования он добавляет? Что если ваш клиент использует другую базу данных? Нужно уничтожить все эти SP и начать с нуля. Не защищайте вас от инъекций sql. Скорость минимальна в большинстве случаев.
Рог
32
Имейте в виду, что большинство крупных ИТ-консалтинговых компаний стремятся максимально увеличить количество оплачиваемых часов, сохраняя при этом свою задницу. Старожилы с любым влиянием в этих фирмах также склонны быть игроками и чиновниками, а не технарями. Я бы взял такие вещи у консалтинговой фирмы с небольшим количеством соли - я несколько раз выводил консалтинговые фирмы из дерьма, исправляя их «лучшие» практики.
ConcernedOfTunbridgeWells
1
Повторное использование кода @Rig добавляется так же, как и для функций любого языка, путем помещения кода в контейнер многократного использования. Конечно, хранимые процедуры действительно защищают вас от внедрения SQL, если вы не выполняете созданную вами строку. Сказать, что скорость минимальна, кажется просто необразованным. В большинстве случаев преимущества в производительности не попадают в одни и те же категории, но демонстрируют большое несоответствие.
Гарет Клаборн
1
@GaretClaborn Но гораздо больше шансов реструктурировать прикладной уровень, чем годы и годы исторических данных базы данных. На любом нетривиальном приложении в любом случае. И если вы это сделаете, вы потратите месяцы на портирование кода с хранимыми процедурами. Добавление еще одной зависимости в ваш проект мало что дает, кроме как в пограничных ситуациях. Они существуют, но большую часть времени это просто добавление еще одного препятствия к гибкости проекта и повторному использованию кода.
Рог
2
Исходя из опыта, в котором мы почти исключительно использовали sps, я могу рассказать вам о преимуществах отказа от них и использования ORM, подобного Entity Framework. Слишком часто бизнес-логика инкапсулируется в процедуру. В то время как вы можете версии Procs с некоторыми рабочими или сторонними инструментами. Это не так просто, как было бы сделать это в рамках, таких как TFS или GIT. Выданный код вашей базы данных не зависит от вашего поставщика RDBMS. Таким образом, вы можете переключить поставщиков RDBMS на более поздний срок с меньшей головной болью.
Ewahner

Ответы:

280

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

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

Эрик Дж.
источник
37
Я не вижу таких вещей просто. Для меня это ВСЕ бизнес-логика. База данных с хранимыми процедурами или без них предоставляет определенные услуги и дает определенные гарантии. В идеале для некорректного кода приложения должно быть невозможным привести базу данных в несогласованное состояние. Если хранимые процедуры необходимы для поддержания этой согласованности, я использую их.
Кевин Клайн
12
@kevin cline: определить «противоречивое состояние». Я согласен с тем, что такие функции БД, как ссылочная целостность, являются ценными и значительно уменьшают вероятность ошибки приложения, вызывающей серьезный ущерб. Однако, вообще говоря, определение «непротиворечивых данных» зависит от правильного выполнения бизнес-правил.
Эрик Дж.
16
добавь мой миллион к миллиону Мейо. Распределенная бизнес-логика уводит вас с шоссе хорошей практики, прямо в переулок безумия
Нико
27
+1 Бизнес-логика, просачивающаяся в DAL, является большой проблемой при использовании хранимых процедур.
Система
30
@ChristopherMahan, я НИКОГДА не хочу использовать базу данных, которую вы разрабатываете. Это наихудшая практика с точки зрения базы данных. Базы данных часто затрагиваются непосредственно в базе данных. Недальновидно думать, что кто-то будет использовать бизнес-уровень для обновления миллиона записей или других событий, происходящих с течением времени. Импорт обычно не проходит через бизнес-уровень (да, я хочу обработать мой 21 миллион записей импорта по одной записи за один раз в бизнес-уровне). Мошенничество намного проще, когда у вас нет ограничений на уровне базы данных. Плохие данные почти на 100% уверены.
HLGEM
163

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

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

Только если вы используете их правильно в контексте, в котором они должны использоваться. То же самое можно сказать о функциях (в структурном программировании) или методах (в объектно-ориентированном программировании), и все же мы видим 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 помогают инкапсулировать эту злобность в одном месте, рядом с данными и без необходимости проходить к серверу приложений.

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

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

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

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

оборота
источник
14
Это действительно хороший ответ.
yfeldblum
5
Хороший ответ, но было ли это иронично? «Обобщения являются матерью всех ошибок».
ночевка
2
Да и нет. Этот мой комментарий был предназначен для этого конкретного предложения, упомянутого ФП в его первоначальном вопросе ( хранимые процедуры не являются «наилучшей практикой» .) Грубое описание процедур хранилища как лучшей или плохой практики является обобщением. Игнорирование контекста, в котором они могут быть хорошими ИЛИ плохими, могут (и часто будут приводить) к
ошибкам
7
+1 за «Типичная маркировка вещей как плохая практика обычно делается в организациях с тоннами некомпетентных программистов». - был там, пережил это, включая то, что мне сказал менеджер по разработке, что он подумал, что у меня есть отличное решение для одной сложной проблемы, но если бы он позволил мне реализовать ее, то это откроет шлюзы для Muppets.
Джулия Хейворд,
1
@ Шейн Вы правы. Однако я полагаю, что этот ответ пытается передать склонность некоторых групп инженеров оправдывать отсутствие знаний или анализа, ссылаясь на карту плохой практики. Ответ может увидеть некоторое улучшение для более неопытных из нас.
Сезар Эрнандес
56

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

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

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

System Down
источник
18
И если ваш хранимый процесс использует любой тип динамического sql вместе со строковым параметром, вы вернетесь к тому, с чего начали.
JeffO
4
Разница в том, что для хранимых процедур может быть установлено разрешение на доступ к каждой процедуре, для параметризованных SQL-запросов вы должны полагаться на здравомыслие программистов, + "blablabla"потому что вы должны разрешить простой SQL, и на этом управление заканчивается.
Кодер
19
Я никогда не понимал аргумент «связывает вас с определенной базой данных». Как часто вы берете свою программу и переносите ее в совершенно другую базу данных?
Мейсон Уилер
11
@MasonWheeler - +1 каждый раз. В любом достаточно большом проекте ваше приложение будет написано с учетом недостатков данного продукта БД. Преобразование в другую БД становится основной задачей, несмотря ни на что, потому что у новой БД будут разные странности!
Майкл Кохне
6
@HLGEM - но в мире COTS несколько БД ожидаются с самого начала (фактически, вы выбираете совместимые БД). Дело не в том, что вы портируете, а в том, что вы поддерживаете разные бэк-энды, что совершенно не похоже на создание порта.
Майкл Кохне
46

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

  • Бизнес и логика приложения должны быть в коде, а не в базе данных. Помещение логики в БД смешивает проблемы.
  • Вы не можете тестировать хранимые процессы так же легко, как код в ваших обычных проектах модульного тестирования с остальной логикой приложения.
  • Я не нахожу хранимые процедуры как способ тестирования первого программирования, когда я пишу код.
  • Хранимые процедуры не так легко отлаживать, как код приложения, когда вы отлаживаете свою программу в IDE.
  • Контроль версий / Контроль версий SP и нормального кода
Жиль
источник
7
Вы также можете легко программировать тестирование в первую очередь для хранимых процедур.
5
Хммм, хорошо ... 1) Использование хранимых процедур в БД не обязательно означает, что в них заложена бизнес-логика. 2) сохраненные процедуры - одни из самых простых вещей для модульного тестирования. 3) процессные хранилища не обязательно являются проводниками тест-первых, правда, но не все, что вычислимо, может быть протестировано в первую очередь. 4) отладка не должна быть проблемой, так как процессные хранилища не должны содержать ничего, кроме простых в проверке операторов SQL и курсоров. Кроме того, отладка должна выполняться сначала путем тестирования и отладки операторов SQL в коде, а затем перемещаться в процесс-хранилище ... просто IMO, кстати.
luis.espinal
6
Вы, очевидно, не разработчик БД. Управление исходным кодом, IDE - чертовски легко отлаживать SP, если вы используете TOAD или аналогичную IDE, то же самое с версионированием.
gbjbaanb
6
2) на модульном тестировании хранятся процы. Подумайте о других инфраструктурах модульных тестов, но, по крайней мере, с MS Test (VisualStudio.TestTools.UnitTesting), для запуска любого из методов Assert в хранимом процессе по крайней мере требуется соединение Db, что по определению делает его скорее интеграционным тестом, чем модульным контрольная работа. И сохраненный процесс может ссылаться на состояние базы данных на глобальном уровне базы данных. Они не могут быть поддельными или иметь интерфейсы.
Т. Вебстер
3
+1 Кроме того, языки хранимых процедур (pl / sql, t-sql, plpgsql и т. Д.) Очень неуклюжи и многословны. Мне гораздо проще использовать язык сценариев для установления соединения с базой данных и обработки бизнес-логики вне базы данных.
22

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

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

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

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

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

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

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

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

оборота серого цвета
источник
1
В Red Gate есть продукт SQL Source Control для SQL Server, но я согласен, что использование логики в хранимых процессах - отличный способ убедиться, что у вас есть важная логика, а не контроль версий.
Carson63000
17
@greyfade - "Я еще не видел контроль версий для SP" - ты шутишь? Процедура хранилища - это просто кровавый текстовый файл, который вы загружаете в свой движок базы данных (который берет его, компилирует и устанавливает для выполнения.) В каждом месте, где я работал, где хранятся процы, мы храним исходный код процедуры хранилища, скажем, CVS, прозрачный или какой-либо другой SCM, который использовался. Сказать, что процессные хранилища не могут контролироваться исходным кодом (потому что они находятся в БД), это все равно, что сказать, что исходный код моего приложения (Java, C # или любой другой) не может контролироваться исходным кодом, потому что он скомпилирован и развернут в производстве.
luis.espinal
2
@ luis.espinal: я не сказал, что они не могут быть в системе контроля версий . Я просто сказал, что я не знал об инструменте, специально предназначенном для ведения истории SP, что подразумевало сохранение этой истории в базе данных. Пожалуйста, не ругайте меня только потому, что вы что-то не так поняли.
Greyfade
1
Все хранящиеся в opur процедуры находятся под контролем источника, просто потому, что вы видели плохие примитивы в прошлом, не означает, что они являются неотъемлемой частью использования хранимых процедур.
HLGEM
1
@ luis.espinal это типично, что источник хранимой процедуры может быть получен позже из базы данных? Если это так, вы можете просто иметь инструмент, который регулярно вытаскивает его, и использовать другие инструменты для воссоздания установки с нуля. Делайте это время от времени, чтобы убедиться, что это точно.
17

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

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

DaveE
источник
10
@DaveE: для корпоративного решения вы, вероятно, правы. Если вы создаете упакованное программное обеспечение, как только вы отправите его на MSSQL, ваша самая большая перспектива захочет запустить его на Oracle.
Эрик Дж.
3
@Eric: слишком верно. Там, где я сейчас нахожусь, мы используем тонны SP и говорим людям «нет», если они не хотят MSSQL. Приятно иметь возможность сделать это.
DaveE
3
@DaveE: Отдел продаж желает, чтобы вы могли сказать «да»?
Эрик Дж.
2
Это не столько перемещение одной системы из одной базы данных в другую, но наличие одной системы, способной использовать любую систему базы данных, которую уже имеет клиент. Большие базы данных стоят дорого.
@EricJ: да, но как только они увидят, сколько будет стоить комиссия, запрос как бы уйдет.
DaveE
17

Все три компании, в которых я работаю, использовали хранимые процедуры для своей логики приложения с 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 / и т. Д., Вы также можете получить от них все, что можете, используя каждое проприетарное расширение, которое вам поможет. ..).

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

Cervo
источник
6
Однако я не могу не предложить пищу для размышлений по всем вопросам, связанным с установкой и процедурой. Я видел курсоры базы данных, используемые во всех случаях, когда такой подход был просто чокнутым. Я лично заменил явный SQL на основе курсора (Oracle PL / SQL, в данном конкретном случае) запросом, ориентированным на наборы, и увидел, что результаты возвращаются в течение секунды, а не 8 минут. Мне потребовалось 30 минут, чтобы разобрать этот 1000-строчный код курсора и «получить» его. Полученный SQL-запрос был лаконичным, элегантным, простым. Люди недооценивают мощность своих серверов баз данных слишком часто и слишком быстро.
Крейг
12

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

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

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

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

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

Кристофер Махан
источник
6
Как вы версии хранимых процедур на сервере? - вы управляете версией исходного кода магазина. Когда пришло время для развертывания, вы берете прокси магазина (с заданной базовой линии) и вы (или ваш dba) развертываетесь в производство. Передислокация (будь то при тестировании или производстве), безусловно, разрушает сохраненный план exec, но это произойдет независимо от того, будете ли вы контролировать свои SP или нет.
luis.espinal
1
@BarryBrown Не работает, если люди имеют прямой доступ к серверу, и может изменять хранимые процедуры. Я должен был бы иметь процесс, который наблюдает за SP, или проверять перед каждым использованием ...
Кристофер Махан
2
Если у вас есть люди, которые просто изменяют sprocs на серверах, не передавая свои изменения в систему контроля версий, у вас есть проблема с процессом, которая почти наверняка влияет на вашу разработку императивного кода, даже если вы не знаете, что это так.
Крейг
1
Одна из вещей, которые я делал в прошлом, заключалась в том, чтобы поместить экземпляр разработки сервера базы данных на отдельные рабочие станции разработчика, или, если это было невозможно, то, по крайней мере, иметь экземпляры «dev» и «production» баз данных. и все сценарии DDL и DML, а также образцы данных и сценарии загрузки находились в своем собственном каталоге в дереве исходного кода, и база данных обычно создавалась из этих сценариев с использованием файла MAKE. Разработчики также могли использовать nmake для создания отдельных хранимых процедур. Если бы они не установили контроль над источником, они бы исчезли, и они это знали.
Крейг
1
... Я не хотел казаться уничижительным в своем предыдущем комментарии с фразой "..., даже если вы не знаете ...". Я хотел сказать, что если подобные вещи происходят с хранимыми процедурами, то, вероятно, это происходит и в других частях проекта. Лично мне не нравится интегрированный контроль исходного кода в IDE, отчасти потому, что я думаю, что это заставляет людей лениво думать о том, что это действительно означает для команды и проекта в целом, чтобы вносить изменения и фиксировать эти изменения в контроле исходного кода. репозиторий. По моему мнению, эти вещи не должны быть «автоматическими».
Крейг
9

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

Вам может понадобиться больше. [ухмыляясь] Серьезно, хранимые процы были в упадке как минимум 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.

Марк Брэкетт
источник
1
Существует МНОЖЕСТВО для повышения производительности, если вам не нужно переносить гигантские наборы данных из базы данных, чтобы делать простые вещи. Измерьте и оптимизируйте, если необходимо.
Точно. Хранимые процедуры можно использовать как скальпель. Это абсолютная гарантия того, что ввод-вывод внутри сервера базы данных имеет большую пропускную способность, чем ввод-вывод между сервером базы данных и вашим промежуточным уровнем. И вы не собираетесь писать более быстрый и эффективный код объединения данных на своем среднем уровне, чем разработчики ядра СУБД, написанные на сервере баз данных. Если вы переносите 1 000 000 строк данных на свой средний уровень, чтобы выполнить объединение, которое я, конечно, видел, вас просто нужно пороть ... Это похоже на парней, которые утверждают, что вы должны "написать свой собственный код отката". Insanity.
Крейг
1
Не стоит недооценивать сервер базы данных. Узнайте, как правильно его использовать.
Крейг
1
FWIW, вам не нужен сохраненный процесс для объединения на стороне базы данных. И если вы используете курсор для процедурной логики, вы, вероятно, уже проиграли войну производительности. Отказ от хранимых процедур, конечно, не то же самое, что отказ от SQL или решений на основе множеств.
Марк Брэкетт
1
Совершенно верно, и я на самом деле спорил в пользу SQL больше, чем спор специально для sprocs. Но тогда встраивание SQL в ваш императивный код не обязательно является ключом к счастью, верно? Это часто приводит к полному обсуждению ORM, что приводит меня к тому, что я указываю на сравнение производительности между ORM-управляемым доступом к БД и простым изучением использования SQL. Я как видел, так и слышал о системах, где, скажем, консультанты Oracle рекомендовали не допускать никакой нагрузки на сервер базы данных, что приводило к тяжелому (и чрезвычайно дорогому!) Промежуточному программному обеспечению с ужасной производительностью.
Крейг
4

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

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

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

Rimbik
источник
4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

оборота user21007
источник
1
Этот ответ сфокусирован на том, чтобы связать вопрос о том, следует ли использовать хранимые процедуры, с вопросом, на кого вы работаете и каковы их мотивы. Downvote. Вместо этого ответ должен сосредоточиться на том, чтобы связать вопрос о том, использовать или нет хранимые процедуры, плюсы и минусы хранимых процедур. Если бы ответ был сфокусирован на идее о том, что ИП не допускают попадания в базу данных, я бы не проголосовал. Я был бы не согласен, в интересах раскрытия, но я бы не понизил.
yfeldblum
Также вы связали статью 2004 года, ИМХО с тех пор ситуация немного изменилась. ИЛИ / М стали намного более обычным явлением. Ruby / Rails ActiveRecord, MS выпустили linq & EF, Django для python и т. Д.
Brook
@ Справедливость, он прав, хотя, зависит ли лучшая практика области Storageprocs от того, кем является компания и какую роль они играют. Например, хранимые процедуры позволяют вам устанавливать разрешения для самого процесса, а не непосредственно для таблицы. Если вы выполняете какую-либо финансовую работу и должны учитывать средства внутреннего контроля, они являются единственным жизнеспособным вариантом защиты ваших данных от пользователей. Но если вы создаете продукты COTS с несколькими возможными бэкэндами, они слишком специфичны для базы данных. Если вы являетесь консалтинговой фирмой, вам может потребоваться рассмотреть несколько различных подходов, которые лучше всего подходят для сложившихся обстоятельств.
HLGEM
3
@HLGEM Я не возражаю против того, что ты поднял. Но я возражаю против тезиса ответа, что основная причина, по которой администратор БД может использовать логику в приложении, заключается в том, что он является консультантом и намеревается обмануть клиента. Это связывает моральное состояние человека с его выбором, использовать ли хранимые процедуры. По моему мнению, у обеих сторон есть технические аргументы , и аргументы обеих сторон будут отличаться от приложения к приложению, от технологии к технологии, от компании к компании, от отрасли к отрасли. И я сначала поищу заслуги, прежде чем оспаривать мотив.
yfeldblum
Он сказал, что работает в консалтинговой фирме. Сохранение большего контроля над кодом по сравнению с хранимыми процедурами, которые развертываются на сайте клиента, является очень законной причиной, по которой это может быть их «наилучшей практикой». Это может быть не «ввернуть клиента», но вполне может быть проблемой большего контроля.
Джесси
3

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

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

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

оборота Джеффо
источник
2

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

Уэйн Молина
источник
Downvoters прокомментирует.
SandRock
2

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

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

user281377
источник
2

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

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

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

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

KNB
источник
Интересно, что инструментам генерации кода, по-видимому, так трудно понять, возвращает ли хранимая процедура набор результатов, когда сама хранимая процедура не имеет никаких проблем с этим.
Крейг
2

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

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

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

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

bobobobo
источник
1

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

Кристофер Махан
источник
3
Трудно масштабировать базу данных?
JeffO
1
Это, по крайней мере, значительно дороже (если только вы не используете MySQL), и во многих местах я работал над получением другой лицензии на SQL Server Enterprise Edition, это все равно что вырывать зубы
Бен Ф.
масштабировать базу данных не сложнее, чем масштабировать конец истории на уровне приложения
Брайан Огден,
1

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

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

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

SonOfPirate
источник
0

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

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

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

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

отметка
источник
-1

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

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

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

оборота Хайзон Любатон
источник
Вы сделали несколько предположений: что у ОП есть необходимость в OLAP (не указано в вопросе); что используемая платформа имеет серверы приложений Java (маловероятно, так как тег относится к SQL Server). Ваш ответ также не приносит ничего, что остальные 22 ответа еще не охватили
Адам Цукерман
Я просто говорил, что если я начну новый проект, редко буду использовать хранимую процедуру для операций только для чтения, это просто личный выбор. Я считаю более удобным выполнять большинство кодировок на уровне бизнес-логики, а не на уровне данных.
Jaizon Lubaton
Похоже, это не дает ничего существенного по сравнению с замечаниями, сделанными и объясненными в предыдущих 24 ответах, вряд ли содержание стоит того, чтобы столкнуться с 4-летним вопросом
комнат
-2

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

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

Нико
источник
если вы собираетесь понизить голосование, сделайте это, но хотя бы объясните, почему.
Нико
наверное потому что ты не прав. SP не означает, что вы пишете код там, просто пишете свои запросы доступа к данным (я думаю, что в 99% случаев). Кроме того, простое наложение триггеров и ограничений на модель данных считается «кодом», т. Е. Операционной логикой, а не данными. Отсюда моя точка зрения, что вы не правы.
gbjbaanb
Где вы устанавливаете преобразования для ваших хранимых данных, кроме базы данных?
Крис Трэверс