在SQL Server 2008 R2中构建类别

Question

你好，我看了几个类似的帖子，我正在寻找的东西，但没有一样是我需要完成的。我正在尝试使用SQL Server 2008 R2来构建类别结构。

我想让类别让我们说...服装，电子，家具，工具......等等。

我正在查看一个3字段的表，从一个类别表（类别ID（PK），categoryname，parentID）开始，我发现这是一个标准的做法，可以进行几层深度而不必重构。

问题在于，让我们说（电子 - 光盘播放器 - 光盘换片机），（电子 - 照明 - 工作室照明）或（衣服 - 女性 - 裙子），（服装 - 女性 - 裤子）级别更深？

我该怎么做品牌？我打算有一个品牌表（brandID（PK），品牌） ，然后Category_Brand表（categoryID，BrandID）将品牌链接到类别，当我想使用从数据库填充的级联下拉列表时。

对于其余属性应用于项目本身的更深层属性，我应如何处理？但是依赖于类别？颜色，图案，材质，尺寸？它可以适用于服装，但不适用于电子产品或工具，男士服装的尺码也不同于女士的服装。 或者我想存储修整器尺寸和颜色的床垫，或者我想要存储床尺寸（国王，王后，双床）的床以及存储类型（弹簧，空气，泡沫，水）的家具

我需要什么是根据项目所属的类别将项目特定属性连接到每个项目。在另一个论坛上，我被建议只添加所有misc。属性到项目表并留下我不使用null的项目。我知道这没有意义，在我看来，应该有不同的子属性表与字段相关的字段，他们代表的类别。我想服装的尺寸例如会有一个查找表，其中每个尺寸都有一个（sizeid）和一个链接表，用于多对多关系来连接尺寸和（itemid），尽管这需要一些不同尺寸的表格，因为男士尺码和女士尺码是不同的，或者将所有（类别id）作为父外键的一个表格放在一个表格中，而另一个项目（长度，宽度，高度）的尺寸将存储在其自身中表与（itemid）一起作为外键？

或者将（sizeid）或（dimensionid）权限存储到项目表中是一个好主意吗？

这对我来说似乎对我来说很简单，但我越看越越多，我越来越困惑于正确的构造方式，我希望它对性能有好处，因为这可能会变成高容量应用。但不是每个人都希望这样？

Answer 1

首先尝试了解标准化。这里给你一个好的article。