LINUX.ORG.RU

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

 ,


0

1

Всем привет.

Подскжаите, валидно ли (не нарушает ли это общие принципы или какие-нибудь нормальные формы) сделать следующее:

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


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

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


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

bvn13 ★★★★★
()

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

djnoob
() автор топика
Ответ на: комментарий от djnoob

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

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

hippi90 ★★★★★
()
Ответ на: комментарий от hippi90

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

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

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

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)

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

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

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

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

fbiagent ★★★
()
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 2)
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

yyk ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от yyk

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

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

yyk ★★★★★
()
Ответ на: комментарий от deep-purple

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

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

yyk ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

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

yyk ★★★★★
()
Ответ на: комментарий от deep-purple

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

yyk ★★★★★
()

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

Shulman
()
Ответ на: комментарий от deep-purple

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

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

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

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

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

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

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

yyk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.