MySQL架构优化

Question

我尝试了两种方法，但随着输入大小的增加，我无法决定哪一种方法会做得更好。

首先是背景故事:

我们有产品，每个产品都有一个类别路径(例如配件-鞋子-运动鞋)

我希望将我的产品与其各自的类别联系起来，同时保持与 3NF 规则兼容。

我可以通过两种方式解决这个问题，我可以:

1. 产品和类别之间存在多对多关系(通过将类别路径分解为各个类别并在多对多表中形成关联)

   优点:
   简单易懂。

   缺点:
   多对多关联呈指数级增长!你可以想象为什么，每个产品都有多个类别，而测试用例只涉及25万个产品。我可以直观地看到，随着输入大小的增加，数据库引擎的压力也会增加。

2. 在类别路径和产品之间创建多对多关系，以及在类别路径和实际类别之间创建另一个多对多关系。这对我来说很有意义，因为 250,000 个产品的测试用例中的类别路径仅限于 13,000 个唯一实例，并且与另一个多对多关系中的实际类别关联的这些路径不超过 61,000 行。

   优点:
   数据库需要快速浏览的类别关联少得多(第一种技术中形成的关联为 900,000 个关联，而数据库为 61,000 个关联)

   缺点:
   更多的内部连接。产品连接到类别路径，类别路径又以多对多关系与类别连接。

您认为以下哪种技术更合适？我需要快速检索，因此快速选择语句应该是主要标准。

我意识到这很大程度上取决于正确的索引，但在第一种情况下，行的大小至少增长了 3 倍，而在第二种情况下，有太多的内部联接，我担心速度检索受到负面影响。

Answer 1

好吧，我已经尝试了两种方法。事实证明第二种技术要快得多。产品和类别之间的映射表不可避免地返回比通过存储每个产品对应的类别路径而连接到产品表的category_path和类别之间的映射表多十倍的行数。

这确实是简单的数学。这个故事的寓意是:维护一个字典表(Category_Path)及其定义(类别)，并通过外键将字典表连接到每个相应的项目(产品)。更少的行数让每个人都高兴:)