Question

主要实体：客户客人保留 RoomAssignment

我想实现多房间预订数据库设计。首先，我想先解释一下这个概念：

客户是获得预订的人。
客户一次只能有1个预订
客户可以保留多个房间。

来宾是指定到特定会议室的人。

所以对于表：

Client (client_id(PK), Name) Guest (guest_id(PK), Name)

Reservation (reservation_id(PK), client_id(FK), roomAss_id(FK), checkInDate);
RoomAssignment (roomAss_id(PK), guest_id(FK), roomno(FK));
Room(room_id(PK), roomDetails);

//这里的问题是我不知道如何实现1对多的关系。我的预订应该处理多个RoomAssignment？或者我的RoomAssignment将处理多个guest_id和roomno，然后我会将1个roomass_id传递到我的预订表中？

谢谢，我对这种一对多的关系感到很困惑。我希望有人能够帮助而不是给我负面的帮助。 T_T

另一种尝试：

Room(room_id(PK), roomDetails);
Client (client_id(PK), Name)
Guest (guest_id(PK), Name)
Reservation (reservation_id(PK), client_id(FK), checkInDate);
Booking(book_id(PK), reservation_id(FK), room_id(FK));
Lodging(lodge_id(PK), guest_id(FK), book_id(FK))

（客户，客房，客人已经填写），添加预订，添加预订，添加住宿

这是正确的吗？

Answer 1

（编辑在考虑了这个之后改变了我的建议。这比我最初想的更深刻。）

我的偏好是让预约与房间有多对多的关系（使用桥牌表）。使用ReservationID和RoomID外键调用此表，例如。。。预订。也许你可以想到一个更好的名字。预订是预订的特定房间。然后，我将有另一个桥表来表示访客和预订之间的关系。你可以称之为 Lodging 。住宿是特定的客人被分配到特定的预订（预订的房间）。

这是一个巧妙的谜题。关键是你有几个具体的东西，它们本身就存在，显然是必要的（预订，房间，客人），还有其他几个概念，每个都有自己的属性，并从这些事物之间的关系中产生。如果要正确地进行规范化，您可能会得到比您猜测的更多的表。不要认为这变得更复杂。拥有足够的正确表格将最终简化此。以下是其他一些建议：

花时间在每张桌子的名字上。我上面的建议非常好，但你可以改进它们。预订既是其他事物之间的关系，也是一种思考本身，在另一张桌子上至少有一个外键。
您应该能够描述表上的记录代表什么。如果你不能这样做，那么你的桌子很糟糕。请参阅上文，我如何描述预订和住宿。您的设计可能最终会有所不同，但是当您头脑风暴不同的表时，请确保您可以描述该表上的记录实际上是什么。
考虑让Guest和Client来自同一个表。他们真的都是“联系人”。有人可能会在某个时间成为访客，但下个月可能是客户。当联系人是客户端时，您可能需要额外的数据表（一到0或1）。如果有人要作为访客，您的系统只需要基本的联系信息，但如果他们是客户，那么您需要更多。

多房间预订的数据库设计：一对多

1 个答案: