Нужно использовать триггеры или нет??

Question

[Артём]

У меня при регистрации пользователя, я получаю lastInserdId() и добавляю статичные данные для этого пользователя в различные таблицы, сейчас их 5 (и по мере развития будет больше)
Можно ли и НУЖНО ли использовать для этого триггеры?
Я никогда такими приёмами не пользовался, примеров я искал и не нашел.

Прошу помочь!
допусти при добавлении записи в `users`
нужно добавить в `table2` 1 запись -

INSERT INTO `table2` (`userid`, `value1`, `value2`) VALUES (ТУТ_МОЙ_USER_ID(), 4, 1)

нужно добавить в `table3` 2 записи -

INSERT INTO `table3` (`userid`, `value1`, `value2`) VALUES (ТУТ_МОЙ_USER_ID(), 4, 1)
нужно добавить в `table2`  1 запись - 
INSERT INTO `table2` (`userid`, `value1`, `value2`) VALUES (ТУТ_МОЙ_USER_ID(), 5, 2)

Буду весьма признателен

Answer 1

[Akina]

В общем случае - нет.

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

Так вот именно эта мысль - она некорректная. Причём по совершенно элементарной причине. Данные для вставки в связанных таблицах (не поля связи - других полей) триггер тоже должен откуда-то взять. А вот корректно передать их достаточно непросто. Их нельзя вставить в блок данных основной записи - там просто места для этого нет, сервер перед выполнением INSERT проверяет входные данные на соответствие количества значений количеству переданных данных, соответствие типов, непревышение размеров и пр. Значит, данные придётся передавать за пределами запроса. Да, тут есть варианты, типа определённых пользователем переменных, временных таблиц и протчая - но всё это ненадёжно, сложно и совершенно несопровождаемо. Следует ещё учесть то, что триггеры - это конструкция неотключаемая. Либо она выполняется при абсолютно любом INSERT, и тогда есть определённые проблемы (триггер, предназначенный для работы при INSERT .. VALUES с единственным блоком данных, вряд ли корректно обработает вставку нескольких блоков данных, INSERT .. SELECT или LOAD DATA), либо для выполнения запросов на массовое добавление триггер надо удалять и потом пересоздавать - а если это происходит в конкурентной среде?

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

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

Ненадёжно. Если между вставкой в основную таблицу и получением LAST_INSERT_ID() соединение будет разорвано и затем автоматически восстановлено, то полученное значение будет некорректным (вернее, получите NULL). А свежесозданная запись благополучно "повиснет в воздухе".
Чисто теоретически, базовая таблица пользователей обязана обеспечивать уникальность записи даже без учёта синтетического первичного ключа (например, поле логина явно должно быть уникальным). А коли так, и с учётом того, что все значения для свежевставленной записи нам известны, можно использовать INSERT INTO slave SELECT 'literal', main.id FROM main WHERE uniquecolumn = 'new value'.

PS. Не знаю, почему при обучении вставке данных все начинают с INSERT .. VALUES - как по мне, глубоко порочная практика. Сначала надо изучить и досконально освоить INSERT .. SELECT, и только потом упоминать про INSERT .. VALUES как более простой конструкции, применимой в частных случаях.

Comments

[Артём]

Спасибо большое за развернутый ответ

Answer 2

[Олег]

На ваш вопрос нет однозначного ответа.
База данных сама по себе мало интересна. Тут нужно смотреть в комплексе.

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

Коробочным решениям важен механизм автоматических обновлений (миграций)

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

Еще такой факт пхпешников (питонистов и т.п.) больше чем хороших DBA

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

Comments

[Артём]

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

[Олег]

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

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

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