MySQL：同桌上的许多连接和关系（理论问题）

Question

这是一个更理论化的问题，而非具体情况：

我们假设，我们有一个简化的表格式：

items包含一些基本数据，item_data每个项目的附加属性rel_items设置不同项目之间的树关系。有不同类型的项目（由字段items.item_type表示），其中item_data存储了不同的字段，例如：dog，cat，mouse。

如果我们有一些更大的查询与一些连接和连接（诸如获取项目与其父项具有某些条件与其他项目等等），与将所有不同类型的项目拆分为单独相比，这是否会成为性能问题表格（dog，cat，mouse）并不将它们合并为一个表格？

如果我们将它全部保存在一个基本项目表中，创建视图（狗，猫，鼠标）会不会影响性能？

编辑（如下面评论）：我想到了“物种”，“家养宠物”等作为item_types。每种类型都有不同的属性。使用基本项目表和item_data表的目的是拥有一个基本的“对象”，并根据需要为它们附加尽可能多的属性，而无需修改数据库方案。例如，我不知道应用程序中将有多少动物以及它们具有哪些属性，因此我想到了每次用户创建新动物时都不需要更改的数据库方案。

Answer 1

  

如果我们对某些连接有一些更大的查询...，与将所有不同类型的项目拆分为单独的表（狗，猫，鼠标）并且不将它们合并为单个表格相比，这会成为性能问题吗？ / p>

没有

  

如果我们将它全部保存在一个基本项目表中，创建视图（狗，猫，鼠标）会不会影响性能？

没有

单独的表意味着它们是根本不同的东西 - 不同的属性或不同的操作（或两者都不同）

同一个表意味着它们基本上是相同的东西 - 相同的属性和相同的操作。

性能不是首要考虑因素。

意义是首要考虑因素。

在理清了这些内容的含义，以及项目之间真正的功能依赖关系之后，您可以考虑加入性能。

“狗，猫，老鼠”都是哺乳动物。一张桌子。

“狗，猫，老鼠”是两种食肉动物和一种杂食动物。两张桌子。

“狗，猫，老鼠”是两种传统的家养宠物和一种常规害虫。两张桌子。

“狗，猫，老鼠”是一种很酷的动物和两种讨厌的动物。两张桌子。

“狗，猫，老鼠”是三个独立的物种。三张桌子。

这是关于意义的。

Answer 2

构建可以修改新对象的模式的尝试，在设计数据库时未分析和包含的模式，是在关系数据库的讨论中反复出现的想法。

在经典的关系数据建模中，可以根据关于讨论范围的某些命题来设计关系。这些命题是数据用户可以通过从数据库中检索数据获得的事实。通过在数据库中存储内容来声明基本关系。可以通过对基本关系的操作来获得派生关系。当使用关系数据模型作为指南构建SQL数据库时，基本关系成为表，派生关系成为视图。

但所有这些预先假定在数据库设计开始之前在数据分析期间发现属性。

在实践中，在过去的25年中，大多数数据库都是在后来发现不完整或不正确的分析的基础上构建的。然后根据新的和改进的分析对数据库进行修订，修订后的数据库有时需要维护应用程序代码。可以肯定的是，关系模型和SQL数据库创建的应用程序依赖性比预关系数据库少。

但是尝试提出像您这样的通用数据模式是很自然的，它可以适应任何主题而无需更改架构。这种方法会产生一些后果，它们涉及的成本远远超过仅仅是性能问题。对于小型项目，这些成本非常易于管理，完全通用的架构在这些情况下可能会很好用。

但是在非常大的情况下，基于这些实体及其关系存在数十种实体类型和数百种相关命题，构建“主题不可知”的模式的尝试经常导致灾难。这些发展灾难已有详细记录，较大的灾难涉及数百万美元的浪费。

我无法向你证明这种方法必须导致灾难。但是，从别人的错误中吸取教训往往比冒险重复它们更有价值。

Answer 3

当然，访问连接表中的数据总是会变慢。 但是使用适当的索引可以接受减速（如2x）。

我会将您在查询中使用的常用项目移动到项目表中，并在item_data中仅保留您需要显示的值，这些值不在WhERE和JOIN条件中使用。