Question

我尝试创建一个架构，允许我在供应商网站无法运营时（计划不计划外）定义时间。

由于许多供应商每周7天，每天24小时不间断工作，因此我已经离开了非运营而非运营，因此非运营时间代表的行数最少。

例如，供应商可能无法运作：

On a Sunday
On a recognised holiday date - '1/1/2015'
On a Saturday after 5pm

我对SQL Server并不过分充满信心，但我们已经提出了一个“完成工作”的架构。然而，众所周知，有很好的方法，不是那么好的方式，也不是很糟糕的方式，所有这些都是时尚的，所以我会很感激我对迄今为止的评论和建议。

其中一个关键功能是将WorkingDays和Holidays中的数据一起用于表示WorkingPeriod实体。

无论多小，我都会很感激。

enter image description here

度假

包含所有公认的假期 - 复活节星期一，耶稣受难日等。

HolidayDate

包含假期日期。例如，今年复活节星期一是2015年4月6日。

周日到周一，映射到Asp.Net星期几的枚举。

包含2行的查找表 - 假日或星期几

合并Holiday表和WorkingDay表，以表示可在SupplierNonWorkingTimes表中使用的单个WorkingPeriod实体。

包含代表WorkingDay / Holiday和非操作时间的ID。

Answer 1

这是一个非常主观的问题，因为你已经观察到没有对错，只有不同的方式。我是一个数据库人，但我不知道你的具体情况，所以这只是一些观察 - 你必须自己判断它们是否适合你。

我喜欢我的命名是清晰的，它可以节省所有的后来其他人误解了。如果[WorkingDay]持有一周7天我会称之为[WeekDay]。如果你打算 [假日]举行全天假期我称之为[HolidayDay]。主表[SupplierNonWorkingTime]是关于'不工作'所以我会调用[WorkingPeriod]表[NonWorkingPeriod]。术语 '期间'总是指一整天，所以我会取代'期间' 'day'（让我们暂时忽略开始/停止时间）。
我的第一印象是您的设计过度标准化。该 [WorkingPeriodType]表有2行永远不会改变， [WorkingDay]有7.对于这些非常低的数字我有时更喜欢 char（1）带有检查约束。归一化通常很好，但很多关于琐碎查询的JOIN并不是那么好。你可以消除[WorkingPeriodType]和[WorkingDay]，但你已经提到了你的问题中有.Net枚举，所以如果你有某种ORM 你的.Net代码这种标准化水平可能适合你。
我会在[HolidayDate]表中添加Year字段，然后添加PK 成为更好的HolidayID + Year - 除非你知道某个地方有很多圣诞节'：）
我将一个IsAllDay字段添加到[SupplierNonWorkingTime]表中，否则你必须使用'魔术值'代表'整天'和魔术价值不好。应该有一个检查约束来强制执行只有在IsAllDay = false时才能输入开始/停止时间。

就像我说的那样，只是我的想法，希望它有用。