代码之家 › 专栏 › 技术社区 › Rui

在不直接使用外键的情况下,与许多其他表共享一个表的数据是否正常?

anti-patterns relational-database database-design design-patterns

1

Rui · 技术社区 · 6 年前

有几个独立的表格, table1 , table2 , table3 等等,每个都有主键 . 此外,还有一种共享表 shared_table 有3列- text_value , fake_foreign_key 和 table_name ,它是一个调用 共享表 每个独立的表( 表1 , 表2 , 表3 )需要加入 共享表 通过使用列 假外键 以及 表名 从同一列中获取数据 文本值 .

基于上述设计,很难将独立表与 共享表 直接与 SQL ,但当然有一些人的帮助 程序设计语言 这是可能的。

在关系数据库设计中,基于er建模,两个关系表之间应该存在关系。所以我对上面的设计感到惊讶,因为实际上 没有直接主键和外键之间的关系 共享表 和其他桌子 . 此外,必须以编程方式计算表的映射,因此很难使用 对象关系映射 框架。

这种设计的唯一好处是表的数量比单独创建 文本值 每个参考表的表,即 表1 , 表2 , 表3 ,因为所有的文本值都在同一个表中 共享表

问:这种设计是反模式的吗?我们真的需要这样的设计吗?

3 回复 | 直到 6 年前

1

Rui 6 年前

仅仅为了“少桌子”的担心通常是完全错误的。事实上,当包含名为“table_name”的列时,毫无疑问,设计者非常清楚他实际上是将多个表合并为一个表。在您的例子中:要与表1中的内容关联的text_值,要与表2中的内容关联的text_值,以及要与表3中的内容关联的text_值。

从关系上讲, 它确实是一个完全的反模式,但是SQL语言的几个“特性”有时会迫使设计者进入这些模式。(例如,对分布式密钥)缺乏支持——在不同[相似的]表中强制执行键值的唯一性。此外,“SyrdIdTABLE”的设计者可能更多地考虑要填充它所需的任何UI,看到三个表“完全相同”(它们不是因为他看不到的原因)。决定把它们统一起来会“更好”,所以只有一个程序/窗口/……将需要更新“共享表”。 Waterbed theory . 他在编写大量代码方面节省了一些成本(毫无疑问,在他看来是重复的),而现在系统中其他地方出现了更复杂的操作和完整性强制执行的新成本。

2

3

Jon Heggland 6 年前

简而言之:不必要的糟糕设计。

长话短说:有几件事要考虑。

首先,外键首先是约束 ,一种确保数据完整性/正确性的机制。如果设计排除使用它们,则必须以其他方式确保完整性——使用声明性多表约束(如果DBMS支持它们)、过渡约束(DITTO)、触发器、应用程序代码或没有任何东西,以减少良性。外键简单、可靠、高效。利用它们是明智的。

其次,设计混乱。我使用ER建模和这样的图表,主要用于草图和文档,而不是规范,因为符号不够丰富,无法捕获关系模型提供的所有可能性,并且限制了我的思维。但是这个图表在任何情况下都不能正常工作,因为它并不能清楚地说明这些表是如何协同工作的。你需要一个实质性的文本框来解释,而且图表本身是没有用的。

这些缺点可能超过了拥有更少的表这一值得怀疑的好处。(表是关系模型擅长的,没有理由害怕它们。)但当然,这必须根据所讨论的数据库的全部需求和设计进行评估。

3

0

Alper 6 年前

如果您考虑ER建模中的继承,这很容易解决。考虑一下 base 有主键的桌子 table1 , table2 和 table3 继承自。这将使您的fk1指向该基表的一个实例,并使整个工作。