店可以对我们的产品（鞋，T恤等）。每个产品可以有许多变体，每个变体可以有不同的价格和库存，例如， T恤有不同的颜色和大小
我对这个问题的解决方案中的图片
http://dl.dropbox.com/u/43925242/erd_product_variant.png
描述但这种解决方案有一些缺点
对于这个问题，您可以建议如何简化数据库设计？
=====更新======
那么NoSQL解决方案呢？任何建议？
将您的产品重命名为类别和变体产品;从类别中删除股票（和价格，除非大多数变体的基准价格相同）。这样你有多个产品，与同一类别相关。目前产品和变体之间存在矛盾。
您需要在应用程序级别检查而不是在数据库中检查产品功能。您可以将FeaturesList表（包含FeatureName，必需/可选和CategoryID）链接到Category以简化产品功能验证和搜索模板生成。或者，如果大多数类别具有相似的功能集，则可以创建NN与功能列表的关系;这样的结构有点难以维护，但更加灵活。
顺便说一句，'难以控制'是非论点。如果有严格的规则来验证数据，那么你需要遵循它们;如果没有，那么执行它们也不是你的任务。实施严格的规则清单比试图发明更容易，客户可能需要两三条规则:)
我建议有几个表，类别即T恤，牛仔裤等等，产品即T恤衫A，T恤衫B ，然后是一个Variant表，其中包含ProductID（链接到Product表），Color，Size，Price，inStockQty等详细信息。
我也有刚刚类别ID，产品ID，所以你可以映射一个产品同时出现在多个类别一ProductsInCategories表（认为中性T恤，你可能想显示为两男子T恤和女装T恤）
你将有很多使用ProductsInCategories表和一个产品和变体（一种产品可以有很多变种，但一个变体只能属于一个产品）
缺点之间一对多的关系范畴&产品之间的多对多关系你提到的可以通过设计良好的存储过程和表格来克服，索引也将有所帮助服务表现。使用这种表格结构，控制每个变体（如更新价格等）也应该相当容易。
基本问题是“如何存储父类的异构子类？”。有很多选择 - 你选择的是混合动力车，这不一定是坏事。
我已经看到了这个主题的最好描述是Craig Larman与书“UML和模式应用” - 虽然他是从面向对象的写入，而不是查看数据库点。
首先第一件事情：你已经设置方式“变种”可能不是你想要的东西 - 它表明，“价格”和“股票”一起运动，而他们的数据非常不同的位。我会考虑将它们分解到自己的表格中 - “variant_price”和“variant_stock”。其次，您选择表示要素的选项通常称为“实体属性值”或EAV。它的主要优势在于允许您在设计时不知道其架构的情况下存储数据，但它会使任何布尔查询陷入巨大的痛苦之中 - 想象一下寻找XL尺寸的所有红色T恤。
有在关系世界3倍的替代品（这是基于Larman与书）：每变种
亚型。所以，你创建一个“variant_tshirt”表 大小，颜色等，以及“variant_trouser”有大小，颜色， 腿内侧等，这保持了表很好的和自描述的，但使 您的SQL成一个巨大的烂摊子 - 它必须改变每个子类型。
带有所有可能列的单个表格：在这种情况下，您有一个包含所有子类型的所有可能字段的 单个表格。这样， 你的SQL保持简单得多 - 但表格变得非常糟糕，并且你依赖于你的客户端应用程序“知道”裤子内部腿属性为 ，而T恤衫则不然。
表共同属性 亚型有存储在自己的表其独特的价值。在 这个模型，假设你只有裤子和t =衬衫，你有 一个“变体”表的大小和颜色，和一个“裤子”表内腿 。
每个选项都有优点和缺点 - 尤其是在一个情况下，你不提前知道哪些亚型，你会需要，第一个选项是最简单的数据库结束，而是创建一个位一团糟的客户端代码。
在SQL之外，你可以使用XML - 使用XPath，你可以很容易地执行布尔查询或NoSQL - 但NoSQL在这里不会是我最喜欢的，它们大多数在概念上都是基于键值关系，这使得布尔查询相当困难。
一个问题是那3个替代方案是我不知道什么样的产品将被存储在数据库中。 –
图片的链接已损坏。你介意再把这张照片放进去吗？ – Flux