Работа без хранимых процедур или триггеров

Question

Мы работаем над сложной базой данных и клиентским интерфейсом в течение последних 18 месяцев. Мы регулярно добавляем новые функциональные возможности в это приложение, и теперь оно ежедневно используется десятками пользователей во всех наших офисах, включая сайты и за рубежом. Это просто чтобы сказать вам, что это РЕАЛЬНОЕ приложение с РЕАЛЬНОЙ базой данных.

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

Точно так же нам все еще не нужны были триггеры. Фактически, единственными SP и триггерами являются системные или добавленные для репликации.

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

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

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

РЕДАКТИРОВАТЬ:

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

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

Я должен признаться, что я пытаюсь найти некоторые отстаивающие аргументы, когда все эти фанаты SQL, работающие над другими нашими базами данных, смотрят на нас свысока, говоря своим друзьям: «Вы знаете, что? Они даже не используют SP и триггеры! Ха-ха! «

Answer 1

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

Триггеры имеют ряд применений, от значительного упрощения обслуживания таблиц history (где каждая строка представляет прошедший период времени для основной таблицы) до постановки в очередь запросов на ETL в хранилище данных (зависит на конкретной РСУБД)

Хранимые процедуры также имеют свое место, независимо от того, вызываются они из приложения или из инструментов командной строки SQL.

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

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

Answer 2

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

Нет, вы не можете.

Нормализация и хранимые процедуры полностью отделены друг от друга.

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

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

Answer 3

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

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

Answer 4

Нет ничего, что я ненавижу больше, чем сталкиваться с огромной связкой встроенного SQL в коде, в котором есть ошибка. По крайней мере, с помощью Stored Proc вы можете проверить его синтаксис или даже выполнить, чтобы увидеть, в чем проблема. Не говоря уже о том, что это будет быстрее, чем просто запуск запросов в БД при сохранении плана выполнения. Я давно придерживался мнения, что код БД принадлежит к БД, но это только мое мнение.

И триггеры имеют свое применение. Они не всегда лучшие, но, безусловно, есть причина.

Answer 5

"Сколько триггеров настроено для обновления некоторых полей таблицы или для пересчета итогов или других агрегированных данных?"

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

Вот один пример, когда SP абсолютно необходимы: пользовательский интерфейс - это лишь малая часть всего приложения. И когда весь процесс происходит независимо от пользователей. Например, я работаю над проектом, который включает в себя много обработки данных из разных источников. Итак, мы получаем эти файлы, а затем просто запускаем Script Shell, которая просто запускает SP, чтобы импортировать все данные из файлов, проверить их, манипулировать ими и т. Д. И угадай что? этот же SP может также использоваться пользователем из пользовательского интерфейса, без необходимости перезаписывать все запросы на обработку данных снова!

Конечно, если эти запросы обработки были просто SELECT, вы могли бы поспорить о необходимости SP, но когда вам нужно ОБНОВИТЬ десятки таблиц, вычислить поля, очистить данные, очистить данные, тогда SP будут благословлены. И это не означает, что в нашей базе данных отсутствует нормализация, но когда вы ежедневно обрабатываете миллиарды данных, не все может быть просто.

Answer 10

Если у вас есть семь разных приложений, обращающихся к базе данных пользователей, не имеет ли больше смысла иметь хранимый процесс под названием "createUser", а не семь разных приложений, создающих этот оператор INSERT самостоятельно?

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

Теперь вы можете сменить эти семь приложений, а также новое, чтобы поговорить со сторонним приложением, чтобы получить значение, при построении оператора INSERT.

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

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

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

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

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

Мои $ .02

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