Почему использование триггера в mysql/oracle/mssql ... в web-программирование (и не только) считается признаком говнокода?

День добрый.
Привык по максимуму использовать возможности СУБД. Потихоньку учу Web-программирование (node.js-путь). Часто использую и хранимые процедуры и триггеры. Считаю, что если модифицируются данные в БД, то правильно если сама БД помимо "традиционных" ее ценностей (первичный ключ, индексы, внешние ключи, constraints) должна следить за правильностью (а не только целостностью) хранимых данных в том числе с использованием триггеров (если при изменении одних данных требуется вносить изменение в другие и они связаны дополнительными расчетами, которые не реализуешь просто через внешние ключи). Также ряд методов вносить в хранимые процедуры (и функции), например, расчеты со сложными предварительными выборками данных.
Если СУБД выполняет это быстро и расчеты связаны с данными, хранящимися в ней - то почему многие (в том числе и на этом сайте) считают это говнокодом? Гонять туда сюда данные из таблиц между backend-ом и СУБД для расчета - это хороший стиль ?!

Один ответ я догоняю - зависимость от конкретной СУБД.

Неужели это факт запрещает (в рамках рекомендаций) использовать предоставляемый функционал (смена БД - возможный ход событий, но не запредельной сложности задача ведь переписать код допустим с TSQL на PLSQL? )? Или это для уменьшения затрат перехода на другую СУБД при возможных ошибках запланированного выбора изначальной СУБД ?
  • Вопрос задан
  • 2746 просмотров
Пригласить эксперта
Ответы на вопрос 11
opium
@opium
Просто люблю качественно работать
Да нормально это на оракле бывают вообще всю бизнес логику в СУБД делают
Ответ написан
Adamos
@Adamos
Еще один ответ: правильность данных - это понятие не системы хранения, а бизнес-логики. Вынося это суждение на низкий уровень, вы ломаете аккуратную архитектуру.
Данные не бывают правильными или нет сами по себе. И критерий правильности легко может измениться, при этом не затрагивая хранение совершенно.
Ответ написан
@AVKor
Просто многие веб-разработчики осваивали БД по видяшкам. Какие уж там триггеры?

Потому они, чтобы не выглядеть среди тех, кто БД знает, полными дураками, и придумали такую фишку, что то, что они не понимают - говнокод.
Ответ написан
LeEnot
@LeEnot
Енот-андроид
Триггер это "неявная логика работы". Он добавляет трудности в разборе логики БД, по типу оператора GOTO.
Ну и любое исключение в триггере вызовет немедленный rollback того действия, на которое он был повешен.
Ответ написан
s0ci0pat
@s0ci0pat
I'm Awesome
А вот теперь для точности, пусть все отвечающие еще и уточняют над какими проектами она работают.
Ответ написан
@uelkfr
Они мешают локализации бизнес-логики внутри вашего приложения. Т.е. бизнес-логика разделяется на две части и на два языка программирования. Рассмотрим каждый из недостатков по отдельности.

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

2. Бизнес-логика пишется на двух языках программирования. Во-первых нужно знать, хорошо знать, два языка. Во-вторых, нужно вводить Coding Style Standarts еще для одного языка. В-третьих, языки хранимых процедур (T-SQL, PLSQL и т.п.) не очень подходят для написания сложной бизнес-логики, а современные требования к бизнес-логике как раз требуют софистики. Вообщем код получается запутанным, нечитаемым, сложно модифицируемым и т.д.

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

P.S. На опыте скажу сталкивался с системой КИС УЗ Модус, разработчик отказался разрабатывать сервер и запил всю бизнес логику на T-SQL и вызывал их из клиентского десктопного приложения. Вообщем печальная была система.
Ответ написан
igruschkafox
@igruschkafox
Специалист по сопровождению БД MS SQL
потому что:

- Трудно вносить изменения (изменилась процедура - а триггер на таблице работает по старой логике)
- Трудно сопровождать (проапдейтил таблицу а сработал набор триггеров и в результате обновления справочника появляются различные документы)
- логика системы должна быть в одном месте а не распихана по различным уголкам (обновление системы усложняется)
- Лишние трудности при отладке (правильная работа процедуры или правильное обращение к базе данных вызывает ошибку - потому что триггер может не корректно отработать)
- и все эти проблемы возводятся в квадрат когда один триггер вызывает срабатывание другого триггера на другой таблице!
Ответ написан
streetflush
@streetflush
Есть понятие двухзвенной системы и трехзвенной.
Так вот в двухзвенке это мастхев. А в трехзвенке база должна быть максимально тупой.
А Web это трехзвенная архитектура априори.
Ответ написан
Всю логику стараются собрать в приложении, даже htaccess не пишут длинный, а делают роутинг на уровне приложения. Во-первых если разработчик сторонний работает с приложением он не видит триггера, во-вторых он что-то поменял а триггер всё работает если о нём не знали или просто забыли убрать.
А если у вас приложения почти нет (или оно минимально), а чисто сервер обработки данных какой ни будь, то пожалуйста...
Ответ написан
@Joysi75 Автор вопроса
прошу прощения за неправильную терминологию, но:
Если взять "слои" Web-приложения, то почему нельзя сделать следующее распределение и вынести в СУБД
Model - (СУБД - table, view + возможно stored_procedures, triggers)
Controller - (СУБД - stored_procedures,functions,triggers)
И оставить для веб-программирования "слои" Route и View.

P.S. Ведь и freeware (и т.п. схемы лицензирования) СУБД (mysql ...) имеют эти механизмы и грех ими не пользоваться...
Ответ написан
OnYourLips
@OnYourLips
Это так же плохо, как глобальные переменные и копипаста кода, вместе взятые.

От копипасты тут дублирование кода: в бизнес-логике и в хранилище.
От глобальных переменных - невозможность отслеживания изменений.

Зависимость от конкретной СУБД - это сущие мелочи и совсем не минус по сравнению с теми недостатками, которые я перечислил.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы