mySQL中“组合”查找表相对于单个查找表的缺点

Question

仅使用一个组合查找表（mySQL数据库）来存储表之间的“链接”比使用单独的查找表有大的缺点（可能在查询速度等方面）吗？我之所以这么问，是因为在我的项目场景中，我最终会得到超过100个单独的查找表，我认为设置和维护这些表将会有很多工作。但为了更简单地举例,这里是一个仅包含4个表的简化场景：

表：教师

表：学生

表：类

表：languageSpoken

=================================================================================

表：student_teacher

表:student_class

表：student_languageSpoken

======VS一个组合查找表（带有一个辅助表）=====

帮助器表：allTables

表：lookupTable

Answer 1

查找表通常是静态的，因此不应该有太多的维护开销。但是，如果您更新了查找数据，那么现在必须管理单个查找表的行子集的生命周期，这可能会变得棘手，而不是在新数据可用时截断表。如果您的查找表有不同的模式，并且列必须为null，因为它们应用于给定的“类型”行，那么我会非常小心。您可能无法实现正确的外键。如果您碰巧使用了错误的id，就会得到一个不合理的值。这些帮助您保持数据的一致性（在生产系统中）。如果这是一个学校项目，特别是一个数据库类，你将会因为没有使用教科书的规范化而受到惩罚。

Answer 2

您的第二个查找模式是完全没有用的。

您可以通过表的名称/索引引用表。但是您不能直接使用这个关系（tablename不能参数化），您需要构建条件连接表达式或者使用动态SQL。这比较慢。

您的查找表是可反转的，即相同的引用可以通过两种方式写入。当然，您可以添加CHECK约束，如CHECK table_A （另外，它避免了自引用），但这再次降低了性能。

您的查找不会阻止不存在的关系（例如，类和语言不相关，但不阻止为这种关系创建行）。同样，附加的约束和性能下降。

还有更多的缺点...但我懒得一一列举。

另一点非常重要：确保引用完整性的外键约束不能用于“组合查找”方法。它们需要用复杂且容易出错的触发器来模拟。总体而言，“组合查找”方法只是一个可怕的想法。-粘性钻头

有一个规则--非关系的关系必须分开。

在第一种方案中--一个学生可以同时在多个班级学习吗？如果不需要，则不需要student_class查找表，而class_id是student表中的属性。