方法1

所以我现在的数据库设计是

--------------------------- 
Activity Table 
--------------------------- 
id|name|date_held 

1|see moive|20120901 

2|shopping|20120902 

3|shopping|20120905 

4|shopping|20120906

您可以看到购物记录重复3次。我认为这看起来不太好。

方法2

所以我分成3桌

--------------------------- 
Activity Table 
--------------------------- 



id|name 

1|see moive 

2|shopping 


--------------------------- 
Date Table 
--------------------------- 
id|date 

1|Sep 1 

2|Sep 2 

3|Sep 5 

4|Sep 6 



--------------------------- 
Activity_Date Table 
--------------------------- 
activity_id|date_id 

1|1 

2|2 

2|3 

2|4

但我认为方法2是很迷茫。任何人都可以给我一个建议如何在1场比赛1上做表格设计.. * date_held？

谢谢！

嗨茨尔Dimitrijevic

我想到几个小时后，我发现另一种方法，即使用Redis的JSON格式

{

“名”：“购物“，

”date“：[

“SEP1”

]

}，

{

“名”： “看电影”，

“日期”：

“SEP2 “，”Sep5“，”Sep6“

]

}

这似乎很容易〜：d

不过，让我觉得你的建议..

来源

2012-09-05 Samuel Lui

你可以看到，购物记录重复3次。

的name场的价值，单独服用，不会重复在不同的行。整个记录（即行）不重复。逻辑上，如果在多个日期上重复相同的活动，则必须为这些日期中的每一个日期重复标识该活动的相同数据片段。没有魔法，所有相关组合都必须在数据库中列出。幸运的是，数据库擅长处理大量的数据。

我觉得有两个问题在这里：

你需要一个代理键id？如果永远不会有在同一日期同一活动，则{name, date_held}是一个“自然”键，不管你是否会添加其他“代孕”键，如id。所以除非你使用actually need这个代理PK，你可以把自然键作为主键。如果每天可能有多项活动，请考虑用datetime_held替换date_held。
你需要一个第三个表？如果你想把更多的信息，而不仅仅是每个活动的名字联系起来，或者你希望一个活动能够存在，即使没有被持有，那么无论如何你仍然需要它在逻辑层面。但是，即使你不这样做，在纯物理的水平，在第三台使用替代PK将节省您从重复的字符串，而应该让你重复（苗条）的整数。您可能会节省空间（和缓存性能），但也可能需要更多JOINing。正如你看到的，这是一个平衡的问题，并测量可以为选择合适的一个的宝贵工具。

无论是活动的名称或ID。

来源

2012-09-05 11:13:04

1活动的数据库设计有1 .. * date_held

方法1

方法2

回答

相关问题