这是一种什么样的数据模型
What kind of data model is this
我查看了 "database application" 并发现它大体上由包含名称-值对的平面 table 组成。关系不作为 DDL 存在,而是通过使用帮助程序 table 向其他 table 提供 "pointers" 和提供参考信息的列名。这些关系在运行时通过通用函数解决。
简化示例
在实体之间提供 "relations" 的通用函数的元代码看起来像
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"
这些 "relations" 当然是不完整的,因为并非 table "catalog" 的所有 "values" 都被引用,另一方面,行可以很容易地添加到目录中通过 "just" 添加 table 和列名称到 "Translator" table,创建并链接到应用程序的新引用 table。不用说,我无法为这个应用程序开发 ER 模型,我也不认为这样做有任何意义。
问题:
文献中有专门的术语吗approach/concept?
是否有理论概念描述这种存储数据和创建 "functional/adhoc/indirect" 依赖关系的方式? (我可能不想叫这个"relations")
用"design pattern"来描述上述内容会更好吗?
出于与 EAV 完全相同的原因,它是 EAV, Entity-Attribute-Value, with a more complex mapping from actual DBMS tables to the conceptual tables they represent. It is an encoding of the tables and metadata tables of a DBMS that unfortunately isn't offering or using the metadata and functionality of the actual DBMS that is executing. (Observe how encapsulating EAV translations in functions is the right way to do the wrong thing.) And it is an anti-pattern 的变体。
我查看了 "database application" 并发现它大体上由包含名称-值对的平面 table 组成。关系不作为 DDL 存在,而是通过使用帮助程序 table 向其他 table 提供 "pointers" 和提供参考信息的列名。这些关系在运行时通过通用函数解决。
简化示例
在实体之间提供 "relations" 的通用函数的元代码看起来像
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"
这些 "relations" 当然是不完整的,因为并非 table "catalog" 的所有 "values" 都被引用,另一方面,行可以很容易地添加到目录中通过 "just" 添加 table 和列名称到 "Translator" table,创建并链接到应用程序的新引用 table。不用说,我无法为这个应用程序开发 ER 模型,我也不认为这样做有任何意义。
问题:
文献中有专门的术语吗approach/concept?
是否有理论概念描述这种存储数据和创建 "functional/adhoc/indirect" 依赖关系的方式? (我可能不想叫这个"relations")
用"design pattern"来描述上述内容会更好吗?
出于与 EAV 完全相同的原因,它是 EAV, Entity-Attribute-Value, with a more complex mapping from actual DBMS tables to the conceptual tables they represent. It is an encoding of the tables and metadata tables of a DBMS that unfortunately isn't offering or using the metadata and functionality of the actual DBMS that is executing. (Observe how encapsulating EAV translations in functions is the right way to do the wrong thing.) And it is an anti-pattern 的变体。