你好，我看了一些类似的帖子，看看我想做什么，但没有一个与我需要完成的事情相同。我正在尝试使用SQL Server 2008 R2提出我的类别结构。
我想制作类别，比如......衣服，电子产品，家具，工具......等等。
我正在查看一个3字段表，以类别表（类别ID（PK），categoryname，parentID）开头，我发现这是一种标准做法，可以深入多层而无需重组。< / p>
问题在于可以说（电子产品 - CD播放器 - CD换碟机），（电子 - 照明 - 工作室照明）或（服装 - 女式 - 裙子），（服装 - 女式裤子）可能是一个级别更深的？
我该如何为品牌做些什么？我打算有一个品牌表（brandID（PK），品牌） 然后使用Category_Brand表（categoryID，BrandID）将品牌链接到类别，当我想使用从数据库填充的级联下拉列表时。
对于其他属性应用于项目本身但是依赖于类别的更深层属性，我该怎么办？颜色，图案，材质，尺寸？它既适用于服装，也适用于电子产品或工具，男装也有不同于女装的尺码。 或者我想要存放梳妆台尺寸和颜色的家具，或者我想要存放床尺寸（国王，大号床，双人床）和存放类型（春天，空气，泡沫，水）的床
我需要的是根据项目所属的类别将项目特定属性连接到每个项目。在另一个论坛上，我被建议只添加所有misc。属性到项表，并留下我不使用null。我知道这没有意义，在我看来应该有不同的子属性表，其中的字段与它们所代表的类别相关。我认为服装尺寸例如会有一个查找表，其中每个尺寸都有一个（sizeid）和一个多对多关系的链接表，以便将尺寸与（itemid）连接起来，尽管需要一些不同尺寸的桌子，因为男士的尺码和女士的尺码不同，或者把所有的东西都放在一张桌子上，其中（categoryid）作为一种父外键，另一件物品的尺寸如（长度，宽度，高度）会存放在自己的表和（itemid）作为外键？
或者将（sizeid）或（dimensionid）权限存储到项目表中是个好主意吗？
当我开始时，这对我来说似乎很简单，但是我看得越多，我越是对这种结构的正确方法感到困惑，我希望它对性能有益，因为这可能会变得很高批量申请。但是不是每个人都希望这样吗？