Database design 基于数据结构的数据库设计

我有这样的数据结构：

typedef struct tagSUB_DATA
{
    double measuredValue;
    double standardDeviation;
    double calculatedValue;
    double weightedError;

} SUB_DATA;

typedef struct tagALL_THE_DATA
{
    int aNumber;
    double aDouble;
    SUB_DATA measurements1;
    SUB_DATA measurements2;

} ALL_THE_DATA;

我需要将其存储在关系数据库中

我的查询涉及两个字段，measurements1和measurements2。显然，它们是相同的类型，所以我的第一个想法是创建一个SUB_数据表，并在它们之间创建一个外键链接

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: measurements1 (int, Foreign Key referencing SUB_DATA)
Field: measurements2 (int, Foreign Key referincing SUB_DATA)

Table: SUB_DATA
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

然而，数据的实际背景是，测量1和测量2是不同事物的测量，比如苹果和橙子火箭，它们碰巧都需要测量值、标准偏差等。那么，将测量的苹果和测量的火箭的数据存储在同一个表中是否仍然合适，即使他们使用相同的数据，还是更谨慎地设计它，使火箭和苹果拥有自己设计相同的表格

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: appleMeasurements (int, Foreign Key referencing APPLE_MEASUREMENTS)
Field: rocketMeasurements (int, Foreign Key referencing ROCKET_MEASUREMENTS)

Table: APPLE_MEASUREMENTS
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

Table: ROCKET_MEASUREMENTS
Field: ID (int, Primary Key)
Field: measuredValue (double)
Field: standardDeviation (double)
Field: calculatedValue (double)
Field: weightedError (double)

你认为这两个解决方案中哪一个是最好的？第一种方法似乎不太冗余，但可能存在更大的不一致数据的可能性。或者有没有比我想象的更好的方法来解决这个问题

干杯

请原谅我的苹果/火箭伪数据-我真的不能在这里发布实际代码

额外资料：

---

在这种情况下，我们可以确定火箭和苹果以后不会改变它们的字段，因此我不太担心火箭或苹果中的字段以后会发生什么情况。

为什么不创建这两个表呢，但是它们是否继承自一个通用的度量表？

如果您的SUB_数据确实是Apple和Rockets，并且始终是Apple和Rockets，那么它们都是相同数据结构的实例可能是一个设计问题，可能会使您的代码使用风险更高。您可能希望使用子类，即使结构没有什么不同，只是为了区分类型

如果您将两者混合到同一个表中，您可能会希望更改其中一个表的结构，而不是另一个表的结构，就像您使用同一个类一样。如果这是未来的可能，那么显然不要将它们放在同一张表中。或者，如果他们有共同点，将来可能会有差异，您可以使用多个表

这听起来可能需要做很多工作，但一个像样的对象关系映射（例如Hibernate）实际上可以相当好地处理类层次结构，并拆分需要拆分的部分

---

但无论你做什么，在你100%确定什么是共同的，什么可能会改变之前，不要启动你的数据库

您总是有两个精确的测量值吗？如果是这样的话，您根本不需要中断表，只要有一个表，其中包含两组用于两个度量的列

Table: ALL_THE_DATA
Field: ID (int, Primary Key)
Field: aNumber (int)
Field: aDouble (double)
Field: measuredValue1 (double)
Field: standardDeviation1 (double)
Field: calculatedValue1 (double)
Field: weightedError1 (double)
Field: measuredValue2 (double)
Field: standardDeviation2 (double)
Field: calculatedValue2 (double)
Field: weightedError2 (double)

对于结构之间的非可选1:1关系，将子结构嵌入父表在设计上是可以接受的，而且效率很高

---

但是，这使得添加第三种度量类型更加困难。

如何在RDBMS中继承表？我想这取决于您使用的数据库，但POSTGRES支持继承。您可以模拟继承，这并不困难，但很笨重，这就是为什么要使用ORM为您这样做的原因。嗯。错误的建议。现在启动数据库，并更改它，直到您喜欢为止。一旦你学到了新的东西，再改变它。我不同意这种情况。如果您不知道两个关键实体是同一个实体还是不同的实体，那么最好先仔细考虑，而不是以后重构。我不认为识别身份和类型是不成熟的优化。在这种情况下，我们可以确定火箭和苹果不会改变他们的领域。