我必须在关系数据库上建模以下场景。
我正在考虑这样的结构:
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 *列:
等等。所以,在“x”行,我已经建模了
用户001将在00:00和00:59之间接听电话,同时接听电话 电子邮件从星期一00:00到01:29。
思考了一段时间之后,这种方法似乎足够简单,但我担心在与数千名用户打交道时会遇到性能和磁盘空间问题。
事实上,对于10k用户,我会有(10k * how_many_services * 7days)行,这意味着210.000条记录。不是那么多,但用户可能会增长,或者可能会添加新服务。
你能建议一个更好的方法吗?
答案 0 :(得分:0)
这是一个糟糕的设计。它根本没有正常化。
我认为用户和他们的活动时间表之间存在1:很多关系。我会这样建模。
如果您不知道正常形式是什么以及为什么它们很重要,那么您不应该进行关系建模。让懂得它的人帮助你。
答案 1 :(得分:0)
我会为TIMES,SERVICES,USERS和ACTIONS提供单独的表格。
TIMES只包含时间分割(包括时间段的文字说明) 服务将具有诸如answer_phone,answer_email等服务类型。这允许将来容易扩展。 用户可以获得有关系统用户的任何信息。比如userID,name,department等等。 ACTIONS表用于使用外键将所有上述表链接在一起。
actions表中的条目将拥有自己的主键user_FK,time_FK,service_FK。