Question

我目前正在开发一个Web应用程序，它将Cooks的信息存储在用户表中。我们的功能是从我们的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菜肴。这意味着厨师可以在不同的日期和时间收取不同的烹饪费用。

目前，我们正在寻找一种能够满足我们要求并且比我们的解决方案消耗更少空间的智能解决方案。

Answer 1

要回答您的问题，我应该了解更多有关信息结构的信息。例如，如果大多数厨师在某段时间内可用，那么使用

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

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

这会减少行数。

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

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

Answer 2

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

我不知道厨师是否对预定膳食有预期的费用，也就是说，如果一个人没有额外的信息，一般可以假设一个价格。如果是这种情况，那么您可以将这些默认价格存储在存储厨师的表格中。

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

Answer 3

There are a few questions that would help with the overall answer.

How often does availability change?
How often does price change?
Are there general patterns, e.g. cook X is available for breakfast and lunch, Monday - Wednesday each week?
Is there a normal availability / price over a certain period of time, but with short-term overrides / differences?

If availability and price change at different speeds, I would suggest you model them separately. That way you only need to show what has changed, rather than duplicating data that is constant.

Beyond that, there's a space / complexity trade-off to make.

At one extreme, you could have a hierarchy of configurations that override each other. So, for cook X there's set A that says they can do breakfast Monday - Wednesday between dates 1 and 2. Then also for cook X there's set B that says they can do lunch on Thursday between dates 3 and 4. Assuming that dates go 1 -> 3 -> 4 -> 2, you can define whether set B overrides set A or adds to it. This is the most concise, but has quite a lot of business logic to work through to interpret it.

At the other extreme, you just say for cook X between date 1 and 2 this thing is true (an availability for a service, a price). You find all things that are true for a given date, possibly bringing in several separate records e.g. a lunch availability for Monday, a lunch price for Monday etc.

人员可用性的数据库设计

3 个答案: