【发布时间】：2017-03-15 16:30:41
【问题描述】：
我查看了一个“数据库应用程序”，发现它由包含名称-值对的平面表组成。关系不作为 DDL 存在，而是通过使用帮助表提供“指针”到提供参考信息的其他表和列名。这些关系在运行时通过泛型函数解析。
提供实体之间“关系”的通用函数的元代码如下所示
FUNCTION Translate (Element)
LOCAL c, t, r
SELECT Table, Column
INTO t, c
FROM Translator
WHERE Item = $Element
SELECT $c
INTO $r
FROM $t
WHERE Name = $Element
RETURN $r
END FUNCTION
在上面的例子中，将被解析为
Translate "Ele1" ==> "Bar"
Translate "Ele2" ==> NULL
Translate "Ele3" ==> "Bar2"
这些“关系”当然是不完整的，因为并非表“目录”的所有“值”都被引用，另一方面，可以轻松地将行添加到目录中，并通过创建新的引用表并将其链接到应用程序中" 将表名和列名添加到“Translator”表中。不用说，我无法为此应用程序开发 ER 模型，我认为这根本没有意义。
问题：
文献中有关于这种方法/概念的技术术语吗？
是否存在描述这种存储数据和创建“功能/即席/间接”依赖关系的方式的理论概念？ （我可能不想称之为“关系”）
用“设计模式”来描述上述内容会更好吗？
【问题讨论】：
-
我不知道这种模式的名称，但我会指出它的一个特点。存储在用户表中的值是数据和元数据的混合体。在传统的关系模型中，DDL 定义数据，DDL 产生的元数据全部存储在系统表中，即数据字典中。用户表不包含元数据。
-
一些设计师喜欢这种东西的原因很简单。它允许即时对数据模型进行一些更改，而无需执行任何 DDL。这允许应用程序程序员在不通过 DBA 运行它们的情况下进行更改，并减慢进程。缺点是它会导致未记录的数据。
-
上述进一步的研究结果有时被描述为“多态关联，有时被归为反模式”
标签： database-design entity relational-database relationship