我必须在关系数据库上建模以下场景。
- 想象一下你有一个数字(比如10000)的人
- 想象一下,这些人中的每一个人可能会,也可能不会,在一天的时间跨度内提供特定的服务。让我们将这些服务称为"接听电话"、"接听电子邮件"one_answers"接听短信">
- 我一天有48个时间跨度(00:00-00:30、00:30-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条记录。没有那么多,但用户可能会增长,或者可能会添加新的服务。
你能提出一个更好的方法吗?
这是一个糟糕的设计。它根本没有正常化。
我想在用户和他们的活动时间表之间有一种1:多的关系。我会那样做的。
如果你不知道什么是正规形式以及为什么它们很重要,你就不应该进行关系建模。找一个了解它的人来帮助你。
我会有单独的TIMES、SERVICES、USERS和ACTIONS表。
TIMES将只包含时间分割(包括时间段的文本描述)SERVICES将具有answer_phone、answer_email等服务类型。这样可以方便地在未来进行扩展。USERS将拥有系统用户的任何信息。比如用户ID、姓名、部门等等。ACTIONS表将用于使用外键将上述所有表链接在一起。
操作表中的条目将有自己的主键user_FK、time_FK、service_FK。