#mysql #sql #database #database-design #erd
Вопрос:
Извините, если это очевидно, но я новичок в разработке баз данных.
Клиент должен сделать заказ перед арендой товара(ов), он заранее предоставляет подробную информацию, такую как даты бронирования, тип товара и т.д. Сотрудник проверяет, доступен ли товар, прежде чем разрешить клиенту арендовать его. Если доступно, он вводит в систему идентификатор товара, дату аренды, дату возврата и т.д.
Правильно ли я сделал, создав для этого две таблицы? Один для бронирования(который включает в себя предлагаемую информацию об аренде) и один для аренды (который включает в себя фактическую информацию об аренде). И если да, то разве у них не было бы отношений «один к одному»? Как я мог обойти эти отношения один на один? Должен ли я объединить две таблицы?
Комментарии:
1. При разработке схемы набросайте запросы (
SELECT, UPDATEи т.д.), Которые будут использоваться. Обычно это помогает вам находить недостатки в схеме и неудобные места.2. Я хмуро отношусь к отношениям 1:1. Однако в данном случае для этого есть разумные аргументы (см. Ответ Имплалера). Подбросьте монетку.
Ответ №1:
Во-первых, поскольку бронирование может никогда не материализоваться в виде аренды, соотношение не совсем 1:1, а 1:(0-1).
Я бы подумал, что правильно, что вы моделируете их как отдельные сущности, так как:
- У них могут быть разные «жизненные циклы».
- Скорее всего, они обладают разными свойствами.
- Аренда, вероятно, будет связана с кучей других объектов по сравнению с бронированием. Эти FK будут иметь смысл для аренды, но не для бронирования.
Комментарии:
1. Могу ли я потенциально иметь нечто подобное: у «Клиента» есть один ко многим с «резервированием товара». И «Бронирование товаров» имеет много общего с «Арендой»
2. @Liam Я не думаю, что должны быть оговорки N:1 против аренды. Это не похоже на то, что вы описывали раньше. В любом случае, в конце концов, это зависит от ваших конкретных потребностей.
Ответ №2:
Возможно, я ошибаюсь, но из того, что я понимаю, у вас может быть только 1 таблица для аренды и столбец с именем status enum (0,1) 0 доступен и 1 арендован. Я предполагаю, что вы не арендуете один и тот же предмет в одно и то же время.
Комментарии:
1. Хммм, но я также должен записать данные о бронировании? Например, идентификатор клиента, запрошенная дата аренды и запрошенная дата возврата, не будет ли слишком неудобно иметь все данные о будущем бронировании в таблице аренды?
2. Возможно, я упрощаю, но у вас может быть 3 таблицы, 1 для клиента, 1 для товара и 1 для аренды, в которых идентификатор клиента и идентификатор элемента указаны как FK, а в таблице аренды также указана дата и статус бронирования