我想向您学习如何设计数据库模式：
即。我的问题是1活动有1 .. * date_held
例如。活动名称是
“看电影”在9月1日有date_held
“shopping”在9月2日，9月5日，9月6日有date_held
所以我目前的数据库设计是
---------------------------
Activity Table
---------------------------
id|name|date_held
1|see moive|20120901
2|shopping|20120902
3|shopping|20120905
4|shopping|20120906
您可以看到购物记录重复3次。我认为这似乎不太好。
所以我分成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？
上进行表设计谢谢！
嗨Branko Dimitrijevic
在我想几个小时后，我发现了另一种方法，即使用redis json格式
{
“名称”： “购物”，
“日期”：[
“SEP1”
}，
{
“name”：“看电影”，
“日期”：[
“SEP2”， “Sep5”， “Sep6”
}
看起来很容易〜：D
但让我想一下你的建议..
答案 0 :(得分：0)
您可以看到购物记录重复了3次。
单独使用name 字段的值会在不同的行中重复出现。整个记录（即行）不会重复。
逻辑上，如果在多个日期重复相同的活动，则必须为每个日期重复标识该活动 1 的同一条数据。没有魔力，所有相关组合必须列在数据库中。幸运的是，数据库擅长处理大量数据。
我认为这里有两个问题：
您是否需要代理键id？ 如果在同一日期永远不会有相同的活动，那么{name, date_held}是一个“自然”键，无论您是否添加另一个“代理”键，例如{{ 1}}。因此，除非您actually need代理PK，否则您可以将自然键保留为主键。如果每天可以有多项活动，请考虑将id替换为date_held。
你需要第三张桌子吗？如果您想要为每个活动关联更多信息而不仅仅是名称，或者您希望活动即使不被保留也能够存在，那么无论如何您都需要它在逻辑层面。但即使你不这样做，在纯粹的物理层面上，在第三个表中使用代理PK可以避免重复一个字符串，而是允许你重复（较瘦的）整数。您可以使用它来节省空间（和缓存性能），但也可能需要更多的JOIN。如您所见，这是一个平衡问题，衡量可以成为选择合适的工具的宝贵工具。
1 是活动名称或ID。