"combined" 在 mySQL 中查找 table 与单独查找 table 的缺点

Disadvantage of "combined" lookup table in mySQL vs individual lookup tables

仅使用一个组合查找 table(mySQL 数据库)来存储 table 之间的“链接”是否有很大的缺点(可能在查询速度等方面)个人查找 tables?我问是因为在我的项目场景中,我最终会得到超过一百个单独的查找 table,我认为这将需要大量的设置和维护工作。但这里举一个更简单的例子是一个只有 4 tables:

之间的简化场景

Table: 老师

teacherID name
1 Mr. X
2 Mrs. Y

Table: 学生

studentID name
4 Tom
5 Chris

Table: class

classID name
7 Class A
8 Class B

Table:口语

languageSpokenID name
10 English
11 German

======================= 个人查找 TABLES ============== ============

Table: student_teacher

studentID teacherID
4 1
5 1

Table: student_class

studentID classID
4 7
5 8

Table: student_languageSpoken

studentID languageSpokenID
4 10
4 11

====== VS 一次组合查找 TABLE(有一个助手 table)=====

帮手table:全部Tables

tableID name
1 teacher
2 student
3 class
4 languageSpoken

table: 查找Table

table_A ID_A table_B ID_B
1 1 2 4
1 1 2 5
3 7 2 4
3 8 2 5

查找 table 通常是静态的,因此不会有太多的维护开销。但是,如果您更新查找数据,现在必须管理单个查找行的子集的生命周期 table 这可能会变得棘手,而不是在新数据可用时截断 table。如果您的查找 table 具有不同的模式并且列必须为空,因为它们适用于给定的“类型”行,我会小心。您可能无法实现正确的外键。如果你碰巧使用了错误的 id,你会得到一个无意义的值。这些可以帮助您保持数据的一致性(在生产系统中)。如果这是学校项目,尤其是数据库 class,你会因为没有使用教科书规范化而受到谴责。

您的第二个查找架构绝对没有用。

您通过 name/index 引用 table。但是你不能直接使用这个关系(tablename不能参数化),你需要构建条件连接表达式或使用动态SQL。这个比较慢。

您的查找 table 是可逆的,即同一个引用可能有两种写法。当然,您可以添加像 CHECK table_A < table_B 这样的 CHECK 约束(另外它避免了自引用),但这又会降低性能。

您的查找不会阻止不存在的关系(例如,class 和语言不相关,但不会阻止为此类关系创建行)。同样,额外的约束和性能下降。

缺点还有很多……懒得一一列举了

Another very important point: Foreign key constraints assuring referential integrity cannot be used in the "combined lookup" approach. They needed to be simulated by complex and error prone triggers. Overall the "combined lookup" approach is just a horrible idea. – sticky bit


有个规矩——非关系关系一定要分开。


在第一个方案中-一个学生可以同时学习多个class吗?如果不是那么你不需要在 student_class 中查找 table,并且 class_idstudent table.

中的一个属性