Какие ассоциации мне нужны между моделями в этом сценарии?

Question

Я делаю систему бронирования с использованием рельсов.

У меня 3 модели - посетители, номера и бронирование.

Посетители могут оставаться в номерах.

Бронирование может иметь много посетителей и быть во многих комнатах (или общих). У бронирования также есть дата начала / окончания.

Посетители могут потенциально перемещаться между номерами в рамках бронирования, и даты начала / окончания этих распределений номеров должны быть известны.

Достаточно ли здесь одной таблицы соединений? То есть visitor_id, room_id, booking_id?

Или как будут выглядеть ассоциации между этими моделями? Буду ли я нуждаться в дополнительных таблицах, т. Е. В распределении номеров.

Большое спасибо.

Answer 1

Я думаю, у вас должна быть таблица room_allocations.

Answer 2

Как-то так должно начаться:

Возможно, есть более удобные способы оплаты бронирования и бронирования номера.С точки зрения ОО, вы можете смоделировать его, используя составной шаблон.Это, вероятно, сделает логику чище.Вы все еще должны были бы сопоставить с таблицами конечно;стоит ли его изучать, зависит от более широких потребностей вашего приложения.

hth.

Answer 3

В бронировании может быть много посетителей, и он может быть во многих номерах (или разделен).У бронирования также есть дата начала / окончания.

Неясно, что вы подразумеваете под словом «или поделились».

В противном случае, общая процедура состоит в перечислении ваших лиц изатем определите отношения между ними.Это будет примерно так - и я не пытаюсь дать здесь однозначные ответы, но чтобы проиллюстрировать, как это может выглядеть:

Сущности

Сначала попытайтесьопределите свои атрибуты и сгруппируйте их в сущности.Создание словаря данных - это хорошо, особенно если вы работаете в команде.

Отношения

Попытайтесь быть конкретным - говоря, что бронирование может иметь , многие посетители менее полезны по сравнению с присвоением названию отношения (семантика * очень важно для проектирования системы).

Говоря бронирование, сделанное посетителем (-ями) / посетителем (-ями), забронировавшим бронирование лучше, потому что оно позволяет вамРазличайте отношения с именем: бронирование производится для посетителей / посетителей, забронированных (и также помогает вам понять, есть ли у вас оба, и помогает определить количество элементов; также может помочь название их обоими способами, хотя иногда вы заканчиваетеиз-за неуклюжего языка - который может указывать или не указывать на проблемы с дизайном, например, здесь посетитель (-и), забронировавший бронирование , звучит плохо и заставляет меня задаться вопросом, если бронирование само по себе не является таблицей отношений - a слабая сущность ).

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

Примечание: Наличие таблицы трехсторонних отношений «многие ко многим» может быть денормализовано нетривиальным способом .И одна из причин, по которой нормализация очень важна, заключается не в том, чтобы иметь красивый, идеалистический дизайн базы данных, а в том, чтобы иметь возможность управлять потенциальными несоответствиями в вашей базе данных (например, если вы решите денормализовать дизайн, чтобы знать, какие аномалии в вашей базе данныхможет представлять, что довольно очевидно до 3NF ).

Answer 4

Посетители могут двигаться между номерами в бронировании, и даты начала / окончания этой комнаты ассигнования должны быть известны.

Можно ли создать новое бронирование, если посетитель поменяет номер? В этом случае вам не нужна дополнительная таблица.