将MySQL数据与易用性分离

假设一个简单的酒店预订数据库有三个表

表1：预订 此表包含入住和退房日期，以及一个或多个房间的参考资料和优惠券（如果适用）

表2：房间 此表包含所有酒店客房的数据，包括每晚价格和床位数

表3：优惠券 此表包含所有优惠券的数据

选项#1: 如果您想了解某个月的预订情况以及每次预订的总成本，您必须获取预订、每次预订的房间和优惠券（如果有）

根据这些数据，您可以计算预订的总金额

选项2: 但是，还有另一种选择，即将总成本和折扣存储在预订表中，以便更容易获取这些计算。缺点是，您的数据变得更加依赖，处理起来也更加不灵活。我的意思是，每次更改房间或链接到预订的优惠券时，您都必须手动更新预订表的总成本和折扣

在性能（选项2）和版本数据独立性（选项1）方面，通常推荐什么

更新：

---

这是一个MySQL数据库，目前有超过50万行（保留），但正在快速增长。我希望在早期阶段优化数据库性能，以确保用户体验保持快速响应。

答案的响应取决于数据库的大小。对于小型数据库选项#1更好，但对于大型数据库选项#2更好。所以，如果您能说出表中有多少行，以及所使用的数据库（oracle、sqlserver等），您将得到更精确的答案。

让我开始用一个故事来回答这个问题。（有点简化。）

2011-01-01我预订了一个房间，住两晚，分别是2011-03-01和2011-03-02。你别告诉我我会住哪个房间。（因为你还不知道我会住哪个房间。）你告诉我每晚40美元。我没有优惠券。您可以将我的预订输入您的计算机，即使您已经为这两个晚上预订了全部房间。事实上，你已经有一个人在这两个晚上的等待名单上了。（超售是正常现象，不是异常现象。）

2011年01月15日您将每个房间的价格提高5美元

2011年02月01日我再次打电话确认您还有我的预订。您确认我预订了2011-03-01和2011-03-02两晚，价格为40美元。（不是你现在的45美元。那不是我们的协议。我们的协议是每晚40美元。）

2011-02-12单人电话取消了2011-03-01和2011-03-02的预订。你还没有一间你肯定知道我可以入住的房间。等待名单上的另一个人现在有一个房间；我还在等待名单上

2011-02-15单人电话取消了2011-03-01和2011-03-02的预订。现在我有一个房间了

2011-03-01我用优惠券办理登机手续

• 您可以将“当前”或“默认”价格存储在每个房间或每个类别的房间中 房间，但您需要存储我们与我的客户商定的价格 预订
• 预订不预订房间；他们预定了可能的房间。你 不知道谁会早退，谁会晚退，谁会晚退 取消等等。（根据我的经验，偶尔会有一个房间 用犯罪现场的胶带封住。你也不知道这会持续多久。）
• 您可以预订比房间晚更多的房间
• 优惠券可能会在退房前的任何时间出现

如果您想了解某个特定项目的预订情况 每个月的总预订费用，您必须取 预订、每次预订的房间和优惠券（如有） 存在）

我不这么认为。你同意的价格应该在预订单上。在最后一分钟之前，无法合理分配特定房间。如果每个预订都有一张优惠券，那么可能也需要和预订一起存储

---

唯一的报告问题是确保您的报告清楚地报告由于超额预订而应忽略的预期收入。

我看到这是一家旅馆，所以我认为这是一个小基地。因此，请使用干净的数据库：选项#1。@Catcall：感谢您提供了清晰的示例。它展示了一个简单的例子是如何变得相当复杂的。然而，你的回答并没有完全回答我最初的问题。这个例子只是一个问题的例子，也就是说，让数据尽可能独立是最佳做法还是建议。换言之，使用最初的示例，是否最好将成本从预订中抽象出来，仅根据其与房间和优惠券的关系进行预订，或者出于性能原因，是否最好将成本（作为缓存机制的一种形式）包括在内？@BartJacobs:在数据库中，第一个问题——性能、灵活性和独立性——是设计糟糕的表。您的示例没有太多或太少的抽象、灵活性、性能或数据独立性。预订表只是缺少了一些列——例如，我们商定的价格。你不是在“从预订中提取成本”；你“省略了一个必要的栏”。添加商定的价格增加了灵活性（将当前价格和商定价格解耦）、独立性（更改价格不会影响早期预订）和性能（减少加入）。很棒的见解。感谢您的支持，Catcall。首先确保选项#1中的查询已完全优化，然后再寻找进一步的优化。