简短的问题： 如何管理出现在多个类别下的产品类别？完全这样做是不好的做法？
背景资料：
我们有一个产品数据库，其类别如下：
Products
-Arts and Crafts Supplies
-Glue
-Paper Clips
-Construction Paper
-Office Supplies
-Glue
-Paper Clips
请注意，胶水和纸夹分配给两个类别。 虽然它们出现在这个类别树的两个不同位置， 它们在数据库中具有相同的类别ID。为什么？两个原因：
- 为类别分配属性 - 例如，回形针可以具有重量，材料，颜色等。
- 分配到胶水类别的产品显示在工艺品和办公用品下。这是预期的 - 它们与数据库中的实际类别ID相同。
这允许我们管理单个类别及其属性和分配的产品，但将其放置在类别树中的多个位置。
我们正在使用 嵌套集模型，所以我们用来支持这个的db结构是：
Category
----------
CategoryID
CategoryName
CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt
因此，Category和CategoryTree之间存在1：M，因为类别树中可能存在给定类别的多个实例。
有没有更简单的方法来模拟这个允许产品类别在多个类别下显示？
只要这是真的，我认为这没有任何问题 所有 胶水适用于两种办公用品 和 工艺用品。
你有什么是一个好方法，虽然为什么不像这样简化第二个表：
类别
ID
名称
子类别
ID
类别ID
SubCategoryID
虽然将来我会注意在两个根类别之间共享子类别。有时最好创建一个独特的产品分类以保持一致性，这样更容易为您管理，并且可能更容易为客户导航。否则，你有一个问题，如果你在胶水页面上来自办公用品，那么你是否也展示了另一条路径？如果没有，您将有两个相同的页面，路径除外，这是SEO的问题。如果你这样做，那么用户可能会感到困惑。
其中最着名的例子是Google Mail，其中分类以这种方式完成。谷歌以其产品的可用性而闻名......
我相信其他单词比“父”单词更可取，实际上只表示XToOne关系......
也许你可以这样说 Product 尽可能多 Categories，所以关系将是ManyToMany。只有显示器才会以类别开头才能到达产品......
这将突出显示一个问题：如果您不限制类别数量，并且您显示带有子类别的类别等等，您最终可能会：
- 一个庞大的类别和产品列表，有许多重复
- 深度很大（可能不可读）
有趣的部分是突出问题，然后想象一个对最终用户来说很好的解决方案。
一个类别可能需要多个父母。但是，无论您在哪个父级中找到类别，其子类别应保持不变。
我已经看到了真正实现这种逻辑并且工作正常的系统。
编辑
为了回答你的问题，我认为我所建议的模型并不像你想象的那样具有限制性。基本上，树的给定分支可以在多个父分支下找到，但是无论在哪里找到它，它都具有相同的子分支。没有任何关于这个可以阻止你挑选一个分支的一些孩子，并使他们成为另一个分支的孩子。
因此，例如，您可以在办公用品和爱好用品下添加胶水类别，如果您在胶水下添加“Crazy Glue（Suppository Edition）”，它将显示在两者中。如果您有可能按逻辑分组在一起但需要按其用途分开的项目，您仍然可以这样做。你可能会把粘液和粘贴物放在业余爱好粘合剂的范畴之下，它属于业余爱好根，但不属于办公室根部。或者你可以这样做并同时拥有一个由买家内部使用的组合类别。你不能做的是忘记在所有相关类别中添加新类型的胶水，只要它在商业模型本体中的任何位置添加它。
简而言之，您在此限制中损失很少，但获得一些结构以帮助避免必须单独管理每个项目的问题。
编辑
假设我已经为模型本身做了一个令人信服的案例，那么仍然存在实施问题。有很多选择，但这是一种方法：
有一个CatalogItem表，其中包含合成主键，标签，可选描述/详细信息文本以及可选SKU（或等效文件）。然后，您有一个多对多的CatalogItemJoin，其中包含子ID和父ID，两侧都限制为CatalogItemTable。
显示为父项的项目是类别，因此它不应具有SKU。仅作为子项出现的项目是产品，因此它应具有SKU。任何物品都有一个以上的父母是好的;这只意味着它属于多个类别。同样，每个父母的多个孩子也没有问题;这将是一个典型的案例，其中包含一些产品。但是，给定一个类别的ID，无论父类如何引导您，其子级都将是相同的。另一个限制是你要避免循环。