一个table的数据在不直接使用外键的情况下与其他多个table共享数据是否正常
Is it normal to share one table's data with many other tables without directly using foreign key
有几个独立的table，table1，table2，table3等，每个都有一个主键。此外，还有一个共享的 table shared_table 有 3 列 - text_value、fake_foreign_key 和 table_name，它被称为 shared_table因为每个独立的 table（table1、table2、table3）都需要使用列 fake_foreign_key 加入 shared_table和 table_name 从名为 text_value.
的同一列中获取一些数据
基于上面的设计，很难直接用SQL加入一个独立的table和shared_table，但是当然，在一些 编程语言 的帮助下，这是可能的。
在关系数据库设计中，基于ER建模，两个关系table之间应该存在关系。所以我对上面的设计感到惊讶，因为实际上没有直接的主键和外键之间的关系shared_table 和其他 tables。此外，table 的映射必须以编程方式计算，因此很难使用 ORM（对象关系映射） 框架。
此设计的唯一好处是 table 的数量比我们创建单独的 文本值 table 的情况小得多对于每个参考 table，即 table1、table2、table3，因为所有文本值都在相同的 table shared_table
提问：这个设计是反模式吗？我们真的需要这样的设计吗？
如果您考虑 ER 建模中的继承，这很容易解决。考虑 base table 和 table1、table2 和 table3 继承的 PK。这将使您的 FK1 指向该基础的实例 table 并使整个事情正常进行。
简短回答：不必要的糟糕设计。
长答案：有几件事需要考虑。
首先，外键首先是一种约束，一种保证数据integrity/correctness的机制。如果设计排除了它们的使用，您将必须以其他方式确保完整性 - 使用声明性 multi-table 约束（如果您的 DBMS 支持它们）、转换约束（同上）、触发器、应用程序代码或什么都没有，以降低善良的顺序。外键简单、可靠且高效。利用它们是明智的。
其次，设计混乱。我主要使用 ER 建模和图表来绘制草图和文档，而不是规范，因为符号不够丰富，无法捕捉关系模型提供的所有可能性，这会限制我的思考。但是这个图在任何情况下都不能很好地工作，因为它没有清楚地表明这些 table 是如何协同工作的。需要大量的文本框来解释，图表本身也没什么用。
这些缺点可能超过 table 数量减少带来的可疑好处。 （表是关系模型所擅长的；没有理由害怕它们。）但是，当然，这必须根据所讨论的数据库的完整要求和设计进行评估。
仅仅为了 "fewer tables" 而担心 "fewer tables" 通常是完全错误的。事实上，当包含名为 "table_name" 的列时，毫无疑问，设计者非常清楚他实际上是将多个表合并为一个。在您的情况下：text_values 与表 1 中的内容相关联，text_values 与表 2 中的内容相关联，text_values 与表 3 中的内容相关联。
相对而言，它确实是一个完整的反模式，但 SQL 语言的几个 "features" 有时会迫使设计人员采用这些模式。 （例如，缺乏对 "distributed keys" 的支持——强制跨 [不同但相似] 表的键值的唯一性。）此外，"shared_table" 的设计者可能更多地考虑 UI 需要填充它，看到三个表 "completely identical"（它们不是，但由于他没有看到的原因）并决定 "better" 统一它们，所以只有一个 program/window/... 需要更新 "shared_table"。 Waterbed theory。他在要编写的代码量方面节省了一些成本（毫无疑问，"duplicated" 在他看来），而新的成本现在以更复杂的操作和完整性实施的形式出现在系统的其他地方。
有几个独立的table，table1，table2，table3等，每个都有一个主键。此外，还有一个共享的 table shared_table 有 3 列 - text_value、fake_foreign_key 和 table_name，它被称为 shared_table因为每个独立的 table（table1、table2、table3）都需要使用列 fake_foreign_key 加入 shared_table和 table_name 从名为 text_value.
基于上面的设计，很难直接用SQL加入一个独立的table和shared_table，但是当然，在一些 编程语言 的帮助下，这是可能的。
在关系数据库设计中，基于ER建模，两个关系table之间应该存在关系。所以我对上面的设计感到惊讶，因为实际上没有直接的主键和外键之间的关系shared_table 和其他 tables。此外，table 的映射必须以编程方式计算，因此很难使用 ORM（对象关系映射） 框架。
此设计的唯一好处是 table 的数量比我们创建单独的 文本值 table 的情况小得多对于每个参考 table，即 table1、table2、table3，因为所有文本值都在相同的 table shared_table
提问：这个设计是反模式吗？我们真的需要这样的设计吗？
如果您考虑 ER 建模中的继承，这很容易解决。考虑 base table 和 table1、table2 和 table3 继承的 PK。这将使您的 FK1 指向该基础的实例 table 并使整个事情正常进行。
简短回答：不必要的糟糕设计。
长答案：有几件事需要考虑。
首先，外键首先是一种约束，一种保证数据integrity/correctness的机制。如果设计排除了它们的使用，您将必须以其他方式确保完整性 - 使用声明性 multi-table 约束（如果您的 DBMS 支持它们）、转换约束（同上）、触发器、应用程序代码或什么都没有，以降低善良的顺序。外键简单、可靠且高效。利用它们是明智的。
其次，设计混乱。我主要使用 ER 建模和图表来绘制草图和文档，而不是规范，因为符号不够丰富，无法捕捉关系模型提供的所有可能性，这会限制我的思考。但是这个图在任何情况下都不能很好地工作，因为它没有清楚地表明这些 table 是如何协同工作的。需要大量的文本框来解释，图表本身也没什么用。
这些缺点可能超过 table 数量减少带来的可疑好处。 （表是关系模型所擅长的；没有理由害怕它们。）但是，当然，这必须根据所讨论的数据库的完整要求和设计进行评估。
仅仅为了 "fewer tables" 而担心 "fewer tables" 通常是完全错误的。事实上，当包含名为 "table_name" 的列时，毫无疑问，设计者非常清楚他实际上是将多个表合并为一个。在您的情况下：text_values 与表 1 中的内容相关联，text_values 与表 2 中的内容相关联，text_values 与表 3 中的内容相关联。
相对而言，它确实是一个完整的反模式，但 SQL 语言的几个 "features" 有时会迫使设计人员采用这些模式。 （例如，缺乏对 "distributed keys" 的支持——强制跨 [不同但相似] 表的键值的唯一性。）此外，"shared_table" 的设计者可能更多地考虑 UI 需要填充它，看到三个表 "completely identical"（它们不是，但由于他没有看到的原因）并决定 "better" 统一它们，所以只有一个 program/window/... 需要更新 "shared_table"。 Waterbed theory。他在要编写的代码量方面节省了一些成本（毫无疑问，"duplicated" 在他看来），而新的成本现在以更复杂的操作和完整性实施的形式出现在系统的其他地方。