我在数据库中基本上有两个表,一个名为“Valve”,另一个名为“Channel”。这是一种基本的“一对多”关系,这意味着一个 Valve 可以控制多个 Channel。见下图:
在此图中,您可以看到四个子图。第一个子图(day0),显示Valve0(V0)正在控制3个通道(C0,C1和C2),Valve1(V1)正在控制Channel3(C3)。
这是一个非常基本的“一对多”关系,因此我创建了两个表,一个名为“ValveTable”,另一个名为“ChannelTable”。在“ChannelTable”中,它有一个名为“ValveID”的外键,它指向“ValveTable”的主键。
但在我的情况下,树结构会每天发生变化。在day1,C0的属性会发生变化,那么我是否需要在“ChannelTable”中复制C0行?因为我需要记住day0的树层次结构。另外,C2 在第 1 天连接到 V1,因此连接发生了变化。
第2天,C1从V0中移除。在第3天,一个新的Channel C4被添加到ChannelTable中,因此它得到了新的树层次结构。
我不知道如何设计整个数据库结构。我需要添加第三个表吗?就像连接表或“连接表”之类的东西,比如“多对多”关系数据库?
有什么好主意吗?整个图很大,这是一个非常简化的问题,核心问题是我需要在数据库中保留树结构更改历史记录。
谢谢。
我需要在数据库中保留树结构更改历史记录。
然后你需要存储“每天的频道”。
即,这里的一个直接解决方案是向
DayNo
添加一个字段,例如 Channels
,与 ID
形成复合 PK,这意味着 Channels
中的每个条目都唯一地代表“某个特定日期的一个频道” ”:
Valves {
ID PK
}
Channels {
ID PK
DayNo PK
ValveID FK -> Valves.ID
}
然后,人们可以考虑将
Channels
分成 Channels
(只是列表,包括“过时的”列表),以及 - 比如说 - ChannelsPerDay
,以实现更多的标准化,但这增加了我认为的额外复杂性仅当频道必须拥有有关频道的更多信息而不仅仅是 ID 时,才需要保证。
无论如何,为了完整起见,这里是相应的结构,其中
Name
字段为示例提供了更多实质内容:
Valves {
ID PK
Name UK // assuming we want unique names
}
Channels {
ID PK
Name UK // assuming we want unique names
}
ChannelsPerDay {
ChannelID PK FK1 -> Channels.ID
DayNo PK
ValveID FK2 -> Valves.ID
}