Правильно ли я составил структуру бд по заданию?

Question

[AlpineMilk]

Всем привет у меня есть задание:

Создайте простую систему бронирования жилья (сам бэкэнд, не нужен фронт) .
Основа:
- квартиру можно снять на сутки (минимальное количество - 1 сутки)
- одна квартира имеет в один момент Х свободных слотов т. е. может быть сдана в аренду для X людей одновременно (не обязательно с одним бронированием что-то вроде общежития / размещения с возможностью бронирования кроватей)
- при бронировании более 7 дней мы предоставляем скидку X%
- пользователь при бронировании определяет начальную, конечную дату и количество человек / кроватей.

Реализация будет на симфони, но думаю для моего вопроса это не важно.
Как сделать для кроватей/квартиры? К таблице user_appartament добавить поле beds и при выборе целой квартиры вставлять сюда количество слотов с сущности appartament? Или лучше добавить ещё одно булево поле full в которой буду обозначать, что будет снята вся квартира?
Если есть лучшее предложение по структуре бд или название таблиц, то прошу предлагать)

Comments

[Модератор]

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

Answer 1

[Николай Чуприк]

Я бы рассматривал в качестве основой единицы бронирования не квартиру, а кровати.

SLOTS — принадлежность кровати квартире

slot_id | apartment_id | ( price и прочее свойства кровати... )

RESERVATIONS — резервирование слотов — ссылка на бронирование. В одном бронировании может быть несколько слотов (кроватей), тогда будет несколько строчек на одно бронирование (с одинаковым booking_id)
slot_id | booking_id

BOOKINGS — бронирования

booking_id | user_id | start_date | end_date | ( discount  и прочее, что хотите... )

Количество гостей хранить избыточно, т.к. число строк в RESERVATIONS с данным booking_id и будет числом гостей.

Ну и дальше всякое информационное наполнение по пользователям и квартирам:
USERS
user_id | name | email | ...
APARTMENTS
apartment_id | address | ...
Общее количество слотов в квартире, опять-таки, хранить не надо, т.к. оно определяется количеством строк в таблице SLOTS для данной apartment_id.

Чтобы определить количество забронированных слотов на любую дату $checking_date в квартире $apartment_id надо осуществлять довольно сложный запрос:

SELECT COUNT( slot_id ) FROM SLOTS WHERE
    apartment_id = $apartment_id AND
    slot_id IN ( 
         SELECT slot_id FROM RESERVATIONS WHERE
             booking_id IN (
                   SELECT booking_id FROM BOOKINGS WHERE
                         start_date <= $checking_date AND end_date > $checking_date
                    )
          )

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

OCCUPIED
date | apartment_id | n_occupied | n_available