Question

我想在我的数据库中存储许多不同的产品（以及在一个表中）。借助继承（每个具体类型的表），我将所有公共字段（日期，客户，orderID）保留在父表中，并为一个产品创建一个子表。

一个子表=＆gt;它拥有许多不同产品，具有相同和不同的领域

cat apps*.txt |
    where {$_ -ne ""} |
    Sort-Object -Property @{Expression="DisplayName"} |
    sc all_apps.txt

现在我制作了TableAllProduct，表格字段为{A，B，C，D，F}

有理由选择这个设计，因为我正在考虑我未来的新产品，例如，如果我们用这些存在的字段{A，B，C，D，F}获得新产品，那么我们应该能够存储新的TableAllProduct表中的产品数据没有任何软件升级（而是根据需要新代码的继承方法创建新表）

TableAllProduct可以容纳三种不同的产品ProductOne = {A，B，C} ProductTwo = {A，B，D} ProductThree = {A，B，F}

下一步是将数据存储在TableAllProduct

中

根据给定的情况，ProductOne和ProductTwo具有公共字段{A，B}但是A字段存储来自ProductOne以及ProductTwo的数据

ProductOne有以下选项== {data__A_1，data__A_2，data__A_3}

ProductTwo有以下选项== {data__B_1，data__B_2} 我从其他桌子（曼尼到曼尼）带来了

这里我们打破了RDBMS的规则，因为我在一列需要多个外键，但是RDBMS不支持，删除/编辑外键的职责/功能可以用DELETE_trigger（它将检查类别中的记录）表）

通过这种方式，我现在和将来可以在表格中存储多个产品。

这种方法的缺点是什么？

有没有其他可能的解决方案以更好的方式解决这个问题。（我知道实体 - 属性 - 价值模型，但在我们的情况下，产品不会每天/每周基数改变而且EVA太复杂了维持）。谢谢

Answer 1

您需要规范化数据。

您所描述的模型可以运作。您需要让AllProducts表仅包含所有产品的共同属性（列）。名称和SKU等属性，也可能是对供应商/供应商的引用。

确定公共属性后，可以将其余属性移动到特定于每个产品的表中。 SpecificProduct表可以使用AllProducts表的PK作为PK和FK。 SpecificProduct中的每条记录也将在AllProducts表中有一条记录。特定产品的完整数据包含AllProducts表中的属性，这些属性连接到特定产品表的列。

当不同的属性子集与表中的一小部分记录相关时，此策略有助于使AllProducts表宽度保持较小。通过重用AllProducts PK作为特定产品表的PK / FK，您可以确保连接性能也很好。

一个表用于具有相同字段但数据范围不同的不同产品？

1 个答案: