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

主要实体： 客户 客人 预订 房间分配

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

客户是获得预订的客户

客户端一次只能有一个预订

客户可以预订多个房间

客人是被分配到特定房间的人

因此，对于表格：

客户端（客户端id（PK），名称）

客人（客人id（主键）、姓名）

//这里的问题是，我不知道如何实现一对多关系。我的预订可以处理多个房间的分配吗？或者我的RoomAssignment会处理多个客人id和roomno，然后我会将1个roomass\u id传递到我的预订表中

谢谢，我真的对这种一对多的关系感到困惑。我希望有人能帮我，而不是给我负面的评价。图特

另一次尝试：

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))

（客户、房间、客人已满）、添加预订、添加预订、添加住宿

这是正确的吗？

（编辑在仔细考虑后改变了我的建议。这是一个比我最初想象的更深的谜题。）

我的首选是预订与房间有多对多关系的房间（使用桥接表）。把这张桌子叫做“预订”和“房间号”外键，比如。预订。也许你能想出一个更好的名字。预订是指预订的特定房间。然后，我会有另一张桥牌桌，代表客人和预订之间的关系。你可以称之为住宿。住宿是指分配给特定预订（预订房间）的特定客人

这是你的一个漂亮的拼图。关键是，你有几个具体的东西，它们各自存在，而且显然是必要的（预订、房间、客人），但也有一些其他的概念，每个概念都有自己的属性，并且源于这些东西之间的关系。如果要正确地对其进行规范化，您可能会得到比您想象的更多的表。不要认为这会变得更复杂。拥有足够多的合适的表将最终简化这个过程。以下是一些其他建议：

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

  ---

是的，每个房间都应该有一位客人在上面登记。那么一个房间也应该有一位客人。先生，还有一个问题，我在哪里可以获得预订id，因为我计划最后添加预订。我的订单如下：房间（已填写价值/详细信息等）、客户、客人、房间分配和预订。谢谢你的回答。你能给我看看吗。我不太明白。你最好把它拿出来给我看，这样我就容易多了。请：））考虑在预订过程的早期创建一个预订（有很多数据没有填写）。您可能在以后才要求提供数据（cc编号、liscense车牌、他们是否获得折扣等），但可能应该尽早创建记录。当然可以在预订之前创建联系人（客人、客户等），但是预订应该在其他事情之前。并不是说使用该软件的人会知道正在创建预订。先生，这是否意味着我会在预订和住宿之前先添加预订？

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))