在SQL数据库中设计表的过程中,我和我的同事之间存在争议。该表的目的是根据日期和时间存储不同类型参数的值。
我的建议是创建如下表:
id date time temperature pressure duration flowrate steps
1 1/27/2018 11:13:00 24.5 0.343 57 8 pumping start
2 1/28/2018 12:13:00 25.4 0.452 788 10 pumping end
3 1/29/2018 13:13:00 24.5 3.342 332 6 pumping start
4 1/30/2018 14:13:00 30.5 4.323 33 3 vacuum start
5 1/31/2018 15:13:00 24.5 0.358 232 8 pumping start
如您所见,'tags'代表不同的参数,每个参数都有不同的数据类型:double,int,text等。
我的论点是:
作为我同事的想法,表格应如下设计:
id date time tags value(use text data type)
1 1/27/2018 11:13:00 temperature 24.5
2 1/27/2018 12:13:00 pressure 0.343
3 1/27/2018 13:13:00 duration 57
4 1/27/2018 14:13:00 flowrate 8
5 1/27/2018 15:13:00 pressure 9
6 1/27/2018 16:13:00 temperature 30.1
7 1/27/2018 17:13:00 temperature 23.4
8 1/27/2018 18:13:00 steps pumping start
9 1/27/2018 19:13:00 steps pumping end
他的论点是:
显然,我的话还不足以说服他,好吧,也许在这种情况下我错了。所以我需要你建议最佳做法是哪种?为什么?最好给出一些关于标准/规范化的官方参考链接,以便让我的言语更加强大。
答案 0 :(得分:1)
这里有两个可分的问题。
首先是温度和压力这两个参数是否应该通过将它们放在同一行中而绑定到相同的日期和时间。听起来,在现实世界中,这两个参数来自一个观察,它有一个日期和时间。因此,将它们绑定在一起既有效又更好的数据管理。
第二个问题是,使数据库结构独立于特定标签是一个好主意还是一个坏主意。您的朋友设计确实非常像EAV模式或反模式,具体取决于您的观点。这是一场非常深刻的哲学辩论,双方都有激情的游击队。你和你的朋友之间不太可能解决。
我坚定地参与反EAV阵营。我不得不承认,有一些特殊情况,EAV证明是正确的方法。在这些情况下,分析主题以发现数据是不可能或不切实际的,并且您必须在了解项目范围之前捕获数据。
大多数时候,主题的数据分析非常实用且值得,即使耗时。结果是一个数据库,其逻辑结构反映了现实世界的概念结构。当信息需求发生变化时(例如新标签),数据库的结构会发生变化。
更改数据库的结构是劳动密集型的,并且很难转换现有数据。但结果是更好的数据管理,其中DBMS内部的数据定义正在帮助您进行数据管理。它既可以更好地利用机器资源,又可以更好地利用人力资源。
所以我认为你在辩论中是正确的,但不太可能胜过你的朋友。在没有DBMS帮助或阻碍的情况下,您的朋友宁愿自己进行数据管理。祝他好运。当他的项目超出初学阶段时,他将需要它。
答案 1 :(得分:0)
我认为这是最好的方法:
id date time temperature pressure duration flowrate steps
1 1/27/2018 11:13:00 24.5 0.343 57 8 pumping start
2 1/28/2018 12:13:00 25.4 0.452 788 10 pumping end
3 1/29/2018 13:13:00 24.5 3.342 332 6 pumping start
4 1/30/2018 14:13:00 30.5 4.323 33 3 vacuum start
5 1/31/2018 15:13:00 24.5 0.358 232 8 pumping start
因为第二个设计可以有更少的列,但它有很多重复数据,记录1,2,3,4,5具有相同的信息,因为是相同的记录,这可能使数据库更加沉重,并且重复数据。
我希望能提供帮助。