hostadmin
@hostadmin

Создание записей в связанных таблицах — через MySQL триггеры или в коде приложения?

Имеем БД MySQL (InnoDB) или похожую.
Предположим данные разбиты на две таблицы: user и user_profile. Соответственно данные в user_profile связаны 1 к 1 с данными в user.

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

DBA-щики (например) настаивают на том, что правильнее это выносить в БД (database first), повесить триггер, который при создании записи в user, создаст связанную запись в user_profile.

У способа через код такие плюсы и минусы:
+ Наглядность. Любой программист сразу понимает, что вот тут создается запись и другие записи в связанных таблицах.
+ Поддержка любой БД
- Все должны всегда помнить, что надо создавать записи в связанных таблицах (их может быть несколько, они могут меняться).
- Новые люди могут не "уметь транзакции", не знать о всех связях и т.д.
- Использование БД как "тупое" хранилище при кучи возможностей.

У способа через БД такие плюсы и минусы:
+ 100% консистентность
+ Упрощение кода приложения - коду кодово, базе - базово.
- Для новых программистов такое поведение может оказаться "магией".
- Поддерживается не всеми БД (наверно)
- Есть вероятность забыть добавить триггер при добавлении новой связанной таблицы
- При переезде на другую БД надо помнить о триггерах.
  • Вопрос задан
  • 489 просмотров
Пригласить эксперта
Ответы на вопрос 3
@kifirch
Предположим, что данных стало оч много и нам понадобилось разнести эти таблицы про разным БД на наразных серваках
Тогда DBAшники жестко пососут писос с хранимками и FK ( мы рассматриваем это в теме MySQL)
Тогда только транзакции или поддержание консистентности данных на уровне аппликейшена
Ответ написан
Комментировать
@Vitsliputsli
Триггеры очень не очевидная вещь, поэтому если хочется в БД перетащить часть логики, то лучше сделать процедуру для этого.
Ответ написан
@d-stream
Готовые решения - не подаю, но...
Третий вариант: stored procedure[s]* - на входе получающая нужные данные для добавления/изменения, которая уже в рамках транзакции выполнить проверки-записи-вычисления... притом тогда "магию" подвязанных к профилю контактов (еще таблички уже не 1:1) можно спрятать там же... так же как уведомления о смене чувствительных данных, логгирования и еще чего-нибудь потенциально нужного... притом последнее - собственно не потребует ничего менять за пределами такой процедуры.
Ответ написан
Ваш ответ на вопрос

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

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