SQL Связь между двумя таблица

валидно, не нарушает.

Т.е. смущет наличие двух связей: истрия_ротации_бригад -> бригады, вида многие-к-одному и бригады->истрия_ротации_бригад, вида один-к-одному. Или это нормально?

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

Я бы добавил в таблицу истории поле created_at и делал выборку по нему.

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

Или сделать триггер и апдейтить первую таблицу по нему.

Я бы добавил в таблицу истории поле created_at и делал выборку по нему.

И что делать, когда нужен будет весь список бригад и их «последнее участие»? (Да, у меня есть created_at и я не этому рад)

самому следить, сделать триггер

Да начнётся холивар «делать триггеры или следить в приложении»!

Обругайте мой вариант

+ таблица "бригады"
id
...(другие поля)

+ таблица "проекты"
id
...(другие поля)

+ таблица "истрия_ротации_бригад"
id
start_date
end_date
бригада.id - ссылка на бригаду
проекты.id - ссылка на проект
...(другие поля)

Норм.вариант, но тот же гемор с выборкой последних проектов для всех бригад.

Зачем холивар? Триггеры в бд одной транзакцией - без вариантов.

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

На этот счет добавить еще табличку исключительно про этот случай и следить за её актуальностью.

Но зачем? Все изменения в базе делаешь когда логика отработала и там уже крутишь транзакции. Зачем делать откаты-накаты из базы прямо посреди логики? Какой в этом смысл? Что это даёт?

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

Это даёт откатиться перед долгой операцией

Но зачем? Если при работе с базой что-то отвалится, транзакция сама откатится, а если в приложении что-то отвалится, то хрен с ним, оно и не начало еще вставлять/изменять в базе.

Я говорю не о каких-то там сетевых проблемах, а о проблемах бизнес-логики и длительных в её контексте обработок.

Всё равно не понятно, надо пример.

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

Вот у нас есть долгая выборка по ммльенам записей. И результат ее (маленький) надо кудато вписать, а потом еще пару долгих выборок совершить.

Миллионы бригад и объектов у них? Вы там звезду смерти строите? Нееет, это просто трёхзвенщики все такие поехавшие....

А вы таки предлагаете что? Логику на хранимках?

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

Тут я согласен. Я тоже не сторонник тащить сложную логику в триггеры.

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

Так почему же изначально не отбросить идею с триггерами и проуедурами?

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

Чтобы не тащить в приложение всякую мелочь типа создания ключей, каких-нибудь idшников и прочих вещей, которые касаются только бд и её кухни. Зачем всё это кодить? Кинул в бд - она сожрала. Не сожрала - ошибка, rollback.

Зато я вижу злобный оффтопик и злобных буратин, которым везде мерещатся рубанки

В моем варианте тоже ключи создавать врукопашную не надо. Заслал вставку, получил в ответе айдишник(и), и срать что там за номера, работай себе дальше.

Так почему же изначально не отбросить идею с триггерами и проуедурами?

Без анализа каждой конкретной ситуации, а просто выбросить раз и навсегда?

Выбрасывайте, чо. На ту же помойку, куда и свой мозг выбросили...

Тебе лоб тем рубанком стесало и дальше триггеров не видишь? Иди пиши дальше свои хелловорды ))

дальше триггеров не видишь?

Не гоже свои болячки на оппонента проецировать...

Так у ТС-а типичный «хелловорд» на сотни (тысячи) записей. Самое место для трёхзвенки...

А причем тут тс? С самого первого моего камента мы о нем вообще не говорим.

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

Так это ты сам залез в наш разговор, еще и выводы левые сделал. Не надо так. Ну или в отрыве от тс влезай.

Подтверждаю, все правильно сделал...

Так ты сам попросил:

Да начнётся холивар...

а потом начал свою узкозаточенность на меня проецировать )))

Трёхзвенщики - они все такие

Не, ну а что плохого в трёхзвенке? Так говоришь, как будто это сплошь какие-то отморозки.

Так холивар же!.. ))) Нечто я не понимаю: вот пусть хорошие плывут в хороших гробах, а плохие - в плохих!.." ))