我正在从制造产品从头开始设计数据库。关键设计如下:(目前我正在使用 MS Access 2007,但我的最终实现是 SQL Server,即 SQL Server 2008 是最新版本。此外,我将只使用 Express 版本在这个运动。该应用程序将涉及与此数据库接口的.NET 店面)

[1].每个产品可能分为不同的类别。（我决定假设如果产品没有类别，我会强行插入一个名为 'BLANK' 的类别，而不是将其称为 NULL，这样，如果需要，我可以在将来为产品添加类别）1 产品可以有许多类别。1 类别可以属于 1 个以上的产品。将来类别也可能更改为属于不同的产品。

[2].每个产品类别可以分为不同的子类别。（再次，我决定假设如果一个产品类别没有子类别，我将强制插入一个名为 'BLANK' 的子类别，而不是将其称为 NULL，这样，如果需要，我可以将子类别添加到将来的产品类别中）1 产品类别可以有许多子类别。1 子类别可以属于多个产品类别也可以属于不同的子类别。

[3]。每个产品将具有不同数量的属性。每个属性将具有不同的属性值。某些属性的值将取决于其他属性的值。某些属性的值可能不直接取决于其他属性的值，但仍将间接取决于其他属性值的可用性。

我由此开发的设计如下：

0000_Product_Line
ProductLineID (PK)
ProductLineName

0001_Product_Line_Category
ProductLineCategoryID (PK)
ProductLineCategoryName

0002_Product_Line_Category_Association
[PK] ProductLineID（FK 引用表 0000_Product_Line 中的 ProductLineID）
[PK] ProductLineCategoryID（FK 引用表 0001_Product_Line_Category 中的 ProductLineCategoryID）

0003_Product_Line_Sub_Category
ProductLineSubCategoryID (PK)
ProductLineSubCategoryName

0004_Product_Line_Category_And_Sub_Category_Association
[PK] ProductLineCategoryID（FK 引用表 0001_Product_Line_Category 中的 ProductLineCategoryID）

0005_Product_Line_Attributes
AttributeID (PK)
AttributeName

0006_Product_Line_Attribute_Values
[PK] 属性 ID（FK 引用表 0005_Product_Line_Attributes 中的属性 ID）
[PK] 属性值

0007_Product_Line_Attributes_Association
[PK] ProductLineSubCategoryID (FK 引用表 0003_Product_Line_Sub_Category 中的 ProductLineSubCategoryID)
[PK] AttributeID (FK 引用表 0005_Product_Line_Attributes 中的 AttributeID)

现在我最大的问题是如何管理各种产品的属性（最后产品子类别，因为我将所有内容映射到产品子类别，因为即使产品具有或没有类别或子类别，我仍然会强制插入空白类别和子类别）

假设我有以下值：

产品线：
A
B

产品线类别
A A1
A A2
A A3
B B1
B B2

产品线子类别
A A1 a
A A1 b
A A1 c
A A2 x
A A2 y
B B1 m
B B1 n
B B2 p
B B2 q
B B2 r

属性
a att1
a att2
a att3
b att2
b att4
c att1
c att3
c att4
x att2
x att3
y att4
y
ym att7
n attbr
p att2 attbr

属性值
att1 值1
att1 值2
att1 值3
att2 值1
att2 值2
att2 值3
att2 值 4
att3 值1
att3 值2
att4 值 4
att4 值2

现在例如：att1 和 att2 是相关的因此，如果用户选择 att1 的值，则它确定应该向用户提供 att2 的所有值类似地，如果用户选择 att2 的值，则它确定应该向用户提供 att3 的所有值

没有层次结构，如果 att1 和 att2 是相关的，用户应该首先选择 att1，然后选择 att2，反之亦然用户可以选择 att1 或 att2 的值，它应该过滤掉另一个

类似地,如果用户选择 att2 和 att4 的值,它将确定用户应使用 att2 和 att3 的所有值。

这里也没有层次结构，如果 att2 和 att3 和 att4 是相关的，用户应该首先选择 att2，然后选择 att3，然后选择 att4，反之亦然用户可以选择 att2 或 att3 或 att4 的值，它应该过滤其他相关属性

我如何去建立各种属性之间的关系，以便我的过滤器使用 where 子句将正常工作？

我在互联网上做了很多研究，并提出了以下选项：1.为所有产品及其属性使用一个大表。但是这个表的大小将是巨大的，在各个列中有无数的空值，并且它不服务器的目的，因为使用选择读取会极大地影响性能。

在 SQL Server 2008 中使用稀疏列可避免空值的影响。但是，即使稀疏列可以为空值节省空间，但对于非空的值，它们需要的存储空间要比正常存储空间多。此外，表大小仍然很大，无数列影响读取性能。

我应该使用 XML 来存储数据。我不确定如何实现它以及优点或缺点是什么。

我应该将其分解为每个子类别的单独的小表,每个子类别仅将其自身的属性表示为列,而不是整个产品或其类别的属性。然后,我将在我的应用程序代码中将表名作为参数传递。但是这将有 SQL 注入的问题。解决方法是将存储过程与参数化查询一起使用。但是,性能仍然会受到影响,因为数据库引擎无法优化此类查询的查询计划,其中连接仅通过传递

我应该编写 SQL 查询来准备代表其自己的属性的每个子类别的视图 (而不是为每个子类别具有单独的表)。但是要创建视图,我将需要将关系存储在某个地方,因为一些属性直接基于值相互依赖,而一些属性间接地基于值的 avilability 相互依赖。所以我将有这个属性和值的表 (正如我已经设计的),然后我将需要许多对许多递归关系表

我遇到的最后一个选择是 E 数据库设计，它有自己的优点和缺点，包括复杂的查询编写以及自己监控性能，因为数据库引擎无法优化此类数据库的查询计划。此外，这样的 E 数据库失去了大部分关系本质，并且对各种值的约束很难执行，这将涉及很多触发器。

我不确定设计我的数据库的最佳选择是什么。数据库将主要通过应用程序在 SELECT 查询中访问。产品或其类别或子类别或其属性或值的任何插入都将通过数据输入来完成。(直接插入将用于注册客户和产品供应商 / 制造商,我现在假设这将是一个单独的数据库。然后我需要开发某种映射来将供应商 / 制造商映射到产品)

我真的很困惑，我如何实现我的数据库，并面临很多挑战，独自在一个小公司的 IT 团队。

你们所有人的任何帮助都将不胜感激，并被视为巨大的资产。