Question

我必须在关系数据库上建模以下场景。

想象一下，你有一个数字（比如10.000）。
想象一下，这些人中的每一个可能会或可能不会在给定日期的某个时间段内提供给定的服务。我们将这些服务称为“接听电话”，“接听电子邮件”和“接听短信”。
我每天有48个时间段（00：00 - 00：30,0：00 - 01：00,01：00 - 01:30等）
我必须安排7周工作日（1到7天）
每项服务都可以与另一项服务重叠。

我正在考虑这样的结构：

id | user_id | day | t00 | t05 | t10 | [... more timespans ...] | service_type
x    001       1     1     1     0     ...                        'answer_phone'
y    001       1     1     1     1     ...                        'answer_email'
z    002       1     0     0     1     ...                        'answer_phone'

等等。关于t *列：

每个t *列都是一个布尔值
t00表示“服务从00:00到00:29开启”
t05表示“服务从00:30到00:59开启”
t10表示“服务从01:00到01:29开启”

等等。所以，在“x”行，我已经建模了

用户001将在00:00和00:59之间接听电话，同时接听电话电子邮件从星期一00:00到01:29。

思考了一段时间之后，这种方法似乎足够简单，但我担心在与数千名用户打交道时会遇到性能和磁盘空间问题。

事实上，对于10k用户，我会有（10k * how_many_services * 7days）行，这意味着210.000条记录。不是那么多，但用户可能会增长，或者可能会添加新服务。

你能建议一个更好的方法吗？

Answer 1

这是一个糟糕的设计。它根本没有正常化。

我认为用户和他们的活动时间表之间存在1：很多关系。我会这样建模。

如果您不知道正常形式是什么以及为什么它们很重要，那么您不应该进行关系建模。让懂得它的人帮助你。

Answer 2

我会为TIMES，SERVICES，USERS和ACTIONS提供单独的表格。

TIMES只包含时间分割（包括时间段的文字说明）服务将具有诸如answer_phone，answer_email等服务类型。这允许将来容易扩展。用户可以获得有关系统用户的任何信息。比如userID，name，department等等。 ACTIONS表用于使用外键将所有上述表链接在一起。

actions表中的条目将拥有自己的主键user_FK，time_FK，service_FK。

如何为数据库建模日期和时间安排？

2 个答案: