对于数小时的操作，数据库设计的好方法是什么？答案

【问题标题】：What is a good approach for Database design for hours of operation?对于数小时的操作，数据库设计的好方法是什么？
【发布时间】：2013-01-04 02:23:35
【问题描述】：

我正在尝试创建一个需要使用数小时操作并允许用户通过它进行搜索的应用程序（想想 Yelp 是如何做到这一点的）。

我正在讨论什么是好的设计。我唯一能想到的是有一个数据库表，其中包含一个“公司”表的外键，该表列出了一周中的一天以及打开和关闭时间。

Tbl_Hours_Operation
- day_of_week
- open_time
- close_time
- company_id

有没有其他方法更有效？

【问题讨论】：

目前看来还不错……假期呢？
没有人放假。问题解决了！
听起来你想要有一组相当封闭的“标准时间”，你设计的，然后你想要另外一组更经常变化的“例外” " 涵盖假期时间、每个位置的时间变化等内容。
您还需要允许 day_of_week/company_id 对的多个条目来处理一天中关闭一段时间的业务。在一些国家很常见。

标签： sql database database-design

【解决方案1】：

有两张桌子：

operational_hours（company_id、day_of_week、open_time、close_time）

operational_hours_special（company_id、date、open_time、close_time）

您需要连接这两个表以检查特殊时间。

你们的公司是否会在早餐、午餐、晚餐时关闭siesta？如果是这样，我会补充：

operational_hours_closed（company_id、day_of_week、close_time、open_time）

更有趣JOINs！

【讨论】：

对于午餐休息时间，同样可以通过允许公司在operational_hours 表中的每个day_of_week 有多个条目来实现。因此，与其使用一组关闭时间进行联接，不如仅使用两条开放时间记录。
您可以很容易地在其之上构建一个视图，从而为您提供任意日期的正确时间。
@David 我个人偏好明确的关闭时间是确定关闭的具体原因。
@Leonardo：除非他在计算器上运行此程序，否则 7,000 条记录可能不会成为问题。关系数据库非常擅长优化执行路径。存储数据的方式与回答数据问题的方式之间存在很大差异。前者需要适应后者，但不应与其紧密耦合。至于成本效益，我真的看不出糟糕的设计会如何降低成本。好的设计不是“学术的”，而是在各个方面都是实用的。
@Leonardo 您能否详细说明这是一个可怕的实际解决方案并提供更好的解决方案？我仍然对您所说的学术感到非常困惑。如果您指的是“按书”解决方案，那么您在下面提出的解决方案既不是“按书”也不是“实用”。

【解决方案2】：

你的方法看起来不错。只需要注意一些小事：

确保您根据 Company_Id 和 DayOfWeek_Id（并按此顺序）为该表编制索引。它还应该（可能）支持一周中每天的多个条目，以防公司在白天关闭或在夜间开放。

CompanyDayOfWeek
----------------
Company_Id     INT/BIGINT    FK->Company table
DayOfWeek_Id   INT           (this can be a FK or just a hard coded list of IDs)
Open_Time      TIME          if your DB supports a dateless time data type
Close_Time     TIME

【讨论】：