这是一个更理论的问题，而不是特定的场景：
假设，我们有一个这样的简化表格方案：
items包含一些基本数据，item_data每个项目的附加属性rel_items设置不同项目之间的树关系。有不同类型的项目（由字段表示items.item_type），其中存储了不同的字段item_data，例如：狗、猫、老鼠。
如果我们有一些更大的查询，其中包含一些连接和连词（例如获取项目及其父项目与其他项目有一些条件等），与将所有不同类型的项目拆分到单独的表（dog，cat, mouse) 而不是将它们合并成一个？
如果我们将它们全部保存在一个基本项目表中，创建视图（狗、猫、鼠标）会以某种方式影响性能吗？
编辑（如下评论）：我认为“物种”、“家养宠物”等是 item_types。每种类型都有不同的属性。使用基本 item 表和 item_data 表的目的是拥有一个基本的“对象”并根据需要将尽可能多的属性附加到它们，而无需修改数据库方案。例如，我不知道应用程序中会有多少动物以及它们有什么属性，所以我想到了一个不需要每次用户创建新动物时都更改的数据库方案。
如果我们有一些更大的查询和一些连接......，与将所有不同类型的项目拆分到单独的表（狗、猫、鼠标）而不是将它们合并到一个表中相比，这会成为一个性能问题吗？
不。
如果我们将它们全部保存在一个基本项目表中，创建视图（狗、猫、鼠标）会以某种方式影响性能吗？
不。
单独的表意味着它们是根本不同的东西——不同的属性或不同的操作（或两者都不同）
同一张表意味着它们本质上是相同的东西——相同的属性和相同的操作。
性能不是首要考虑因素。
意义是首要考虑因素。
在你理清了这些东西的含义，以及项目之间真正的功能依赖关系是什么之后，你就可以考虑加入性能了。
“狗、猫、老鼠”都是哺乳动物。一张桌子。
“狗、猫、老鼠”是两种肉食动物和一种杂食动物。两张桌子。
“狗、猫、老鼠”是两种传统的家养宠物和一种传统的害虫。两张桌子。
“狗、猫、老鼠”是一种很酷的动物和两种讨厌的动物。两张桌子。
“狗、猫、老鼠”是三个不同的物种。三张桌子。
这是关于意义的。
尝试构建一个可以容纳新对象的模式，这些新对象在设计数据库时没有被分析和包括在内，这是一个在关系数据库讨论中反复出现的想法。
在经典的关系数据建模中，可以根据要断言的有关讨论领域的某些命题来设计关系。这些命题是数据用户可以通过从数据库中检索数据获得的事实。通过在数据库中存储一些东西来断言基本关系。派生关系可以通过对基本关系的操作来获得。当使用关系数据模型作为指导构建 SQL 数据库时，基本关系变成表，派生关系变成视图。
但所有这些都假定属性是在数据分析期间发现的，在数据库设计开始之前。
实际上，在过去的 25 年中，大多数数据库都是建立在后来发现不完整或不正确的分析的基础上的。然后根据新的和改进的分析对数据库进行修改，修改后的数据库有时需要维护应用程序代码。可以肯定的是，关系模型和 SQL 数据库创建的应用程序依赖项比前关系数据库少。
但是尝试提出像您这样的通用数据模式是很自然的，它可以适应任何主题而无需更改模式。这种方法会产生后果，而且它们所涉及的成本远远超过单纯的性能问题。对于小型项目，这些成本是相当可控的，并且完全通用的模式在这些情况下可能会很好地工作。
但是在非常大的情况下，有数十种实体类型和数百个基于这些实体及其关系的相关命题，试图建立一个“与主题无关”的模式往往会导致灾难。这些发展灾难有据可查，更大的灾难涉及数百万美元的浪费努力。
我无法向你证明这种做法一定会导致灾难。但从别人的错误中学习往往比冒着重蹈覆辙的风险更值得。
当然，访问连接表中的数据总是会更慢。但是使用适当的索引，它可能是可以接受的减速（如 2x）。
我会将您在查询中使用的常见项目移动到项目表中，并在 item_data 中仅保留您需要显示的值，这些值在 WhERE 和 JOIN 条件中不使用。