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

Question

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

我还在stackoverflow上阅读了其他类似的问题，但我觉得他们没有提供我需要的答案。

这是要求：

产品目录应按类别构建，每个类别的子类别数量不明，每个子类别的产品数量不明。

应用程序应该能够随意添加类别，子类别和产品。

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

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

让我们考虑一台电脑和一台洗衣机： 计算机属性 - VideoCard，ProcesorType，Memmory 洗衣机-Putere（w），Maximum Preasure，滤水器

两种产品都属于不同的类别和子类别： 电脑 - 电脑类 洗衣机 - 电子类。

候选人I： 在这种情况下，除了名称和价格之类的常见产品属性之外的所有产品属性都将存储在ProductType中。但这会导致很多NULL值和噩梦噩梦。我不认为我可以创建aditional产品类型，因为这将导致是否需要使用ProductType表来添加aditional列。关于我访问数据的方式也存在一些问题，但我认为它们与这个问题无关。

候选人II：

在这种情况下，每个产品类型都会有一个单独的表格及其属性。但我将访问每个产品的数据，我将创建一个单独的数据库调用，导致重复的步骤很多。 此外，我没有看到任何方式可以使应用程序能够添加aditional产品，类别和子类型，而无需开发人员这样做。

候选人III：

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

我很确定这会起作用，但我不认为在格式化的键值对字符串中存储是最好的方法，也可能不是一个好习惯。 此外，我知道反思速度慢，可能会有性能损失。

在设计数据库时，我还有其他更好的选择吗？ 一些例子或链接将非常感激。

Answer 1

您正在查看子类型或产品，其中每个产品只是一个子类型

候选人1被称为“每层次表”或TPH。一个表捕获所有不同的子类型。对于许多子类型，这将变得混乱：它只适用于少数

候选人2被称为“每种类型的表”或TPT。每个子类型有一个表。在Product表中，您有一列用于定义类型（已经存在，称为Discriminator），其中包含ProductID和Discriminator上的超级键。再次，这会使许多类型变得混乱。

候选人3被叫，呃，某事。这是你有很多亚型的最简单的方法。这似乎效率低下，但由于TPT和TPH设计的开销，它最适合用于许多不同子类型的扩展

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