电子商务应用数据库的设计

Question

您好，我正在开发一个电子商务应用程序，我在为产品目录设计数据库时似乎遇到了一些问题。

我还阅读了有关 stackoverflow 的其他类似问题，但我认为它们没有提供我需要的答案。

这是要求：

产品目录应按类别进行组织，每个类别将有一个未知数量的子类别，每个子类别都有一个未知数量的产品。

应用程序应具有随意添加类别、子类别和产品的能力。

子类别将决定每种产品类型的属性。

考虑到我刚才提到的内容，我将提供一个示例以及我考虑的 3 个选项以及为什么我认为它们不好。

让我们考虑一台计算机和一台洗衣机：计算机属性 - VideoCard ，ProcesorType，Memory 洗衣机 -Putere(w) ，Maximum Preasure ，Water filter

这两种产品都将属于不同的类别和子类别：计算机 - PC 类别洗衣机 - 电子类别。

候选人一： 在这种情况下，除了名称和价格等常见属性之外的所有产品属性都将存储在 ProductType 中。但这将导致大量 NULL 值和维护噩梦。我认为我无法创建附加产品类型，因为这会导致需要更改 ProductType 表以添加附加列。关于我访问数据的方式也存在一些问题，但我认为它们与我认为的这个问题无关。

候选人二：

在这种情况下，每个产品类型将有一个单独的表及其属性。但是我将访问每个产品的数据我将不得不创建对数据库的单独调用，从而导致重复许多步骤。此外，我不知道如何使应用程序能够在不需要开发人员的情况下添加附加产品、类别和子类别类型。

候选人三：

在这种情况下，我会将每个属性存储在 FormattedProperties 中的键值对中。我还将在 className 列中存储作为我的模型的类的名称。当我访问数据时，我将使用反射来检查特定类并同时初始化我的对象。

我很确定这会起作用，但我不认为将任何属性存储在格式化的键值对字符串中是最好的方法，也可能不是一个好的做法。我也知道反射很慢，可能会有性能损失。

在设计我的数据库时，我可以考虑其他更好的选择吗？一些示例或链接将不胜感激。

Answer 1

您正在寻找子类型或产品，其中每个产品恰好是一个子类型

候选 1 称为“每个层次结构表”或 TPH。一张表包含所有不同的子类型。这对于许多子类型来说会变得混乱：它只适用于少数

候选 2 称为“每个类型的表”或 TPT。每个子类型有一个表。在 Product 表中，您有一列用于定义类型（已经在那里，称为鉴别器），在 ProductID 和鉴别器上有一个超级键。同样，这对于许多类型都会变得混乱。

候选人3被称为，呃，东西。它是您拥有大量子类型的最简单方法。它看起来效率低下，但由于 TPT 和 TPH 设计的开销，它最适合扩展许多不同的子类型

就个人而言，我将 TPT 用于一些定义明确的子类型，但对许多子类型使用第三种设计。我不喜欢 TPH 冗余列，因为浪费了磁盘和内存（对于固定长度的列，即使为 NULL 也会分配空间）