针对人员可用性的数据库设计答案

【问题标题】：Database Design for a Person's Availability针对人员可用性的数据库设计
【发布时间】：2016-04-24 10:51:21
【问题描述】：

我目前正在开发一个将厨师信息存储在用户表中的 Web 应用程序。我们有一个功能可以从我们的 Web 应用程序中搜索厨师。如果厨师在 2016 年 5 月 3 日不可用，我们希望在用户执行 2016 年 5 月 3 日的搜索时显示该厨师的 Not-Bookable 或 Not-Available 消息。我们想出的解决方案是创建一个名为 CooksAvailability 的表，包含以下字段

ID, //Primary key, auto increment
IDCook, //foreign key to user's table
Date, //date he is available on
AvailableForBreakFast, //bool field
AvailableForLunch, //bool field
AvailableForDinner, //book field
BreakFastCookingPrice, //decimal nullable
LunchCookingPrice, //decimal nullable
DinnerCookingPrice //decimal nullable

使用此架构，我们能够判断用户是否在特定日期有空。但是这种方法的问题在于它需要大量的数据库空间，即如果一个厨师每年有 280 天可用，则必须有 280 行才能反映一个厨师的可用性。

考虑到我们可能有数千名厨师在我们的应用程序中注册，这实在是太大了。如您所见，早餐、午餐和晚餐的 CookingPrice 字段。这意味着厨师可以针对不同日期和时间的烹饪收取不同的烹饪费用。

目前，我们正在寻找一种智能解决方案，既能满足我们的要求，又能比我们的解决方案占用更少的空间。

【问题讨论】：

多少空间是太多空间？

标签： sql-server database-design relational-database

【解决方案1】：

您正在存储每天的记录，导致您进行这种冗余设计的主要错误是您没有充分分离概念。

我不知道厨师是否有给定膳食的预期价格，也就是说，如果没有其他信息，通常可以假设的价格。如果是这种情况，那么您可以将这些默认价格存储在存储厨师的表中。

让我们将可用性和具体价格存储在不同的表中。如果可用性不必存储价格，那么您可以存储可用性间隔。在另一个存储价格的表中，您只需要存储偏离预期价格的价格。因此，您将在表格中定义可用性间隔、当价格与 oter 中的预期价格不同时的特定价格以及在厨师表中的默认膳食价格值，因此，如果没有特殊价格，将使用默认价格.

【讨论】：

【解决方案2】：

要回答您的问题，我应该更多地了解信息的结构。例如，如果大多数厨师在某个时期都有空，那么用

组织您的可用性表可能会有所帮助

avail_from_date -avail_to_date，而不是每天一行。

这会减少行数。

如果每天的价格没有差异，早餐、午餐和晚餐的不同价格可以更好地存储在厨师表中。如果每天没有不同，早餐、午餐和晚餐的供应情况也是如此。

但是，如果您的信息结构需要每天为每个厨师保留记录，这将是 365 * 280 = 102,200 条记录一年，这对于我看来的 sql db 来说并不是很多。如果您将索引放在正确的位置，这将具有良好的性能。

【讨论】：

问题是厨师可以有不同的费率/天/餐。这意味着他可能有 2016 年 5 月 16 日早餐的一个价格和 2016 年 5 月 17 日早餐的另一个价格
例如，如果我们有 10000 个厨师，我们最终会得到 10000 * 280 = 2800000 行（将近 300 万行）。我相信这太多了，不是吗。请指导我，我不是数据库人
如果你需要的话，一般不会太多。我的意思是，如果每天都有不同的价格或可用性，就没有其他办法了。但是您必须分析和规范化您的数据：例如不是每天都有差异，而是像蛾子一样——你必须把它们放在一张桌子上……
所以问题不在于尺寸太大，而在于您究竟需要什么来优化存储真实信息。

【解决方案3】：

有几个问题可以帮助您获得总体答案。

可用性多久更改一次？
价格多久变化一次？
是否有通用模式，例如每周一至周三，Cook X 提供早餐和午餐？
在一段时间内是否有正常的可用性/价格，但有短期覆盖/差异？

如果可用性和价格以不同的速度变化，我建议您分别建模。这样，您只需要显示已更改的内容，而不是复制不变的数据。

除此之外，还需要权衡空间/复杂性。

在一个极端情况下，您可能会有一个相互覆盖的配置层次结构。因此，对于厨师 X，有一组 A 表示他们可以在日期 1 和日期 2 之间的周一至周三做早餐。然后对于厨师 X，还有一组 B 表示他们可以在日期 3 和 4 之间的星期四做午餐。假设日期为 1 -> 3 -> 4 -> 2，您可以定义 set B 是否覆盖 set A 或添加到它。这是最简洁的，但需要通过大量业务逻辑来解释它。

在另一个极端，你只是说在日期 1 和 2 之间的厨师 X，这件事是真的（服务的可用性，价格）。您会找到给定日期的所有真实情况，可能会带来几个单独的记录，例如周一的午餐供应情况，周一的午餐价格等。

【讨论】：