问题描述
假设我的数据库中有30个表，它们都与Notations表具有一对多关系：
设置Notations表的另一种方式（除了为其每个“父级”都包含一个外键列），这将减轻查询性能的负担？该表预计将变得非常大。
（由于每个符号都包含一个parent_table_id，其余的parent_tables具有29个null值-每行要跟踪的29个null，这看起来很多）
即。
SELECT text,table1_id,table2_id,...,table30_id FROM Notations将显示：
id text table1_id table2_id // table30_id
0 "buzz" 74 null // null
1 "foo" null 45 // null
2 "bar" 22 null // null
3 "fizz" 22 null // null
4 "hello" 28 null // null
5 "world" null null // 3
...etc
解决方法
您不应该有一个符号表
主键-外键对的要点是外键的值与主键的值相同。注释表没有意义。规范化是数据库的一个极其重要的方面。我们要减少冗余和复制的数据。 我们不想重复！表示法表会引入多余的数据。在这种情况下，冗余数据可以引用我们可以使用现有数据计算的数据。所有要规范化的表必须仅包含与其自身相关的数据，并且不可计算。
我们可以通过检查外键字段是否已填充以及相关表中是否存在键来计算每个链接。因此，这些链接不适合放在单独的表中。正如您所提到的，这将是一个巨大的表，这正是它仅保存冗余数据的原因。不需要符号表。相反，如果您需要查找链接，则只需编写查询以检查主键和外键之间是否匹配。这就是数据库使用外键的原因。
仅当我们没有任何外键时，注释表才适用。然后，我们将需要一个表来告诉我们每个记录如何与另一个表中的另一个记录相关联。但是，由于您确实有外键，因此该表会导致重复和冗余数据。
,您是正确的，存储30列中不是NULL的列效率低下-这些NULL值通常在每一行中都占用空间。
假设所有id都是相同的类型，则可以简化结构以使其使用：
table_name
table_id
只有两列。不幸的是，我不知道任何允许“条件”外键关系的数据库。尽管我主张定义外键关系，但这可能是您选择不使用它们的情况。
那并不完全令人满意。尽管您可以使用触发器确保某些完整性，但是缺少外键的“级联”功能。您可以使用更多触发器来实现。 uck！
一种选择是为每个表使用单独的符号表：
notations_table1
text,id
notations_table2
text,id
. . .
然后您可以使用union all将它们放在一起：
create view notations as (
select text,id,'table1' as table_name from notaions_table1 union all
select text,'table2' as table_name from notaions_table2 union all
. . .
然后，基础表可以具有格式正确的外键约束-甚至是级联约束。不幸的是，它缺少作为id的单个列。 “真实” ID是table_name和id的组合。
某些数据库具有其他可能会提供帮助的机制。例如，Postgres支持一种继承形式，在这种情况下可能会有用。