Как разработать БД для системы бронирования столиков?

Question

[Gregary]

Всем привет. Нужно разработать систему бронирования столиков ресторанов. Итак, есть таблица 1Рестораны (PlaceId, SomeFields). Есть таблица 3Столики (TableId, SomeFields). Их связывает таблица 2 РестораныИСтолики (PlaceId, TableId). То есть между 1 и 3 связь многие ко многим.

Далее есть таблица 5Заказы(BookId,SomeFields), которая связывается с таблицей столиков через таблицу 4СтоликиИЗаказы (TableId,BookId). Правильно ли я спроектировал это? У ресторанов много столиков, на каждый столик много заказов в разное время. Буду очень благодарен за ответы)

Answer 1

[Mandor]

Вы связали 1 и 3 способом "многие ко многим", это означает, что один и тот же столик может принадлежать нескольким ресторанам, не могу представить как такое может быть? В моём понимании каждый из ресторанов владеет своим набором столиков, в таком случае таблица 2 не нужна, а 1 и 3 должны быть связаны способом "один ко многим".

По поводу заказов: нужна одна табличка с заказами, в которой будет поле id_столика (BookId, TableId, SomeFields). Ваш вариант подошел бы для случая, когда заказ может быть сразу на несколько столиков.

Comments

[Gregary]

Спасибо за совет, ну то есть так: Таблица 1Place(PlaceId,TableId,SomeFields), 2Таблица(TableIdSomeFields), 3Таблица(BookId, TableId), 4 Таблица(BookId,SomeFields). СВЯЗИ: Таблица 1 имеет связь один ко многим с 2-ой. 2-ая имеет связь 1 ко многим с 3-ей. 3-я имеет связь один к одному с 4-ой. Таким образом у нас следующее: У ресторанов много столиков, но у каждого столика один ресторан. У заказов один столик, но каждый столик принадлежит множеству заказов (так как могут бронировать на разное время). Ну и последняя один заказ имеет одни детали заказа.

Только в первой таблице меня смущает, что к примеру данные будут такие(если у нас к примеру 30 заказов в одном ресторане)
+++++++++++++++++++++++++++++++++++
| ЗначениеРесторан1 ЗначениеСтолик1 ДеталиРесторана|
|ЗначениеРесторан1 ЗначениеСтолик2 ДеталиРесторана|
|ЗначениеРесторан1 ЗначениеСтолик3 ДеталиРесторана| итд. То есть меняется только Id столика

Answer 2

[Gregary]

Итак, как же все таки
1)

2)

Все таки мне кажется первый правильнее. Иначе получается что к примеру в первом ресторане 30 столиков а с id от 1 до 30, а во втором Id будут уже от 30 до 60 к примеру. Можно ли как то сделать составной ID типа у одних столиков от 1 до 30 но с PlaceId 1, типа 1_1, 1_2 и тд?

Comments

[Mandor]

По первому варианту я уже высказался - связь многие-ко-многим не нужна. Есть таблица ресторанов с дополнительной информацией, есть таблица столиков, у каждого из них указан id ресторана (один-ко-многим), есть таблица мест за столиками у каждого из которых указан id столика. В таблице заказов у каждого заказа указывайте id столика, либо id места, либо еще одну связанную табличку (один-ко-многим) с местами для каждого заказа (для оптимизации эту табличку можно упаковывать в поля таблицы заказов типа поле id_мест и содержимое, например "1,10,15".

По второму рисунку. Place и Table - все нормально. OrderAndTable нужно только, если у вас в одном заказе бывают несколько столиков.

"в первом ресторане 30 столиков а с id от 1 до 30, а во втором Id будут уже от 30 до 60 к примеру" - никаких проблем и даже если у вас будут вперемешку id столиков разных ресторанов.

"Можно ли как то сделать составной ID типа у одних столиков от 1 до 30 но с PlaceId 1, типа 1_1, 1_2 и тд?" - можно сделать первичный ключ по двум полям сразу, причем второе будет auto_ancrement - нормальное решение, просто с некоторыми ORM'ами можете испытывать некоторые неудобства.