0

我想向您学习如何设计数据库架构：

IE。我的问题是 1 个活动有 1..* date_held

例如。活动名称是

“看电影”在 9 月 1 日举行了 date_held

“购物”已于 9 月 2 日、9 月 5 日、9 月 6 日举行 date_held

方法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 上进行表格设计？

谢谢！！



嗨，布兰科·迪米特里耶维奇

我想了几个小时后，我发现了另一种方法，即使用redis json格式

{

“名称”：“购物”，

“日期”：[

“9 月 1 日”

]

},

{

"name": "看电影",

“日期”：[

“9 月 2 日”、“9 月 5 日”、“9 月 6 日”

]

}

好像很简单~:D

但是让我想想你的建议..

4

1 回答 1

0

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

name field的值，单独来看，确实在不同的行中重复。整个记录（即rows）不重复。

从逻辑上讲，如果同一活动在多个日期重复，则标识该活动1的同一数据必须在每个日期重复。没有魔法，所有相关的组合都必须在数据库中列出。幸运的是，数据库擅长处理大量数据。

我认为这里有两个问题：

  1. 您需要代理键id吗？如果在同一日期不可能有相同的活动，那么{name, date_held}是一个“自然”键，无论您是否会添加另一个“代理”键，例如id. 因此，除非您确实需要代理 PK，否则您可以将自然键保留为主键。如果每天可以有多个活动，请考虑替换date_held为datetime_held.

  2. 你需要第三张桌子吗？如果您希望将更多信息与每个活动关联起来，而不仅仅是名称，或者您希望一项活动即使没有被持有也能够存在，那么无论如何您都需要在逻辑级别上使用它。但即使你不这样做，在纯粹的物理层面上，在第三个表中使用代理 PK 也会使你免于重复字符串，而是允许你重复（更细的）整数。您可以使用它潜在地节省空间（和缓存性能），但也可能需要更多的 JOINing。如您所见，这是一个平衡问题，测量可以成为选择正确测量值的宝贵工具。

1无论是活动名称还是 ID。

于 2012-09-05T11:13:04.373 回答