我已经搬到了一个新的工作场所，我们拥有这个特定的数据库架构。数据库体系结构由4个表
驱动1）主类型
在此定义列代码，名称和描述
第1行 - EmpID - 员工的ID
第2行 - EmpName - 员工姓名
2）主类型数据
在这里，您可以将列代码值定义为行
第1行 - EmpId - 123
第2行 - EmpId - 124
第3行 - EmpName - John
第4行 - EmpName - Jason
3）主类型映射
您可以在此处映射可以映射的列
第1行 - EmpId - EmpName
4）主类型映射数据
您可以在此处映射列的值
第1行 - 主类型数据的第1行 - 主类型数据第3行的ID
第2行 - 主类型数据的第1行 - 主类型数据第4行的ID
这样，您可以在结构中创建任意数量的表/列/关系。有谁知道这种数据库架构叫什么？有什么好处？在看到添加，维护和理解数据后增加了多少复杂性后，我发现很难找到它的好处。
我被告知，它可以避免在表中创建数百个表和内存，这些列将为null。我在RDBMS上工作过很多，没有NoSQL DB的工作经验，但我认为NoSQL在屏幕后面的工作原理是什么？
答案 0 :(得分：4)
“我发现在添加，维护和理解数据后增加了多少复杂性后，我发现很难找到它的好处。”
这是你唯一需要记住这个可怕的想法。 （顺便说一下，这通常用“EAV”或“实体属性值”的通用名称标记。（谷歌那个词，你会发现很多赞美以及很多人对它的嗤之以鼻。你评估和评判各自的论点。）
“通用名称”，因为实际上有许多变体都可能在一些小细节上有所不同。举例说明：你的是一种变体，用一个“实体ID”的常用概念替换记录的实体属性值之间的“映射”。您对该映射的概念是二进制的（对于称为“映射”的东西而言并不罕见），如果您想要将两个以上的实体属性值“映射”在一起，则会产生其他问题。）
那就是说，如果您处于以下所有情况都属实的罕见情况：
- 你真的真正面对“稀疏”数据
- 数据的性质一直在变化（一年一次不是“所有时间”）
- 没有dba技能以正确的方式解决这个问题（= dba方式），或者以正确的方式解决它的应用程序的影响太大而且令人生畏
- 并且数据不可避免地缺乏任何形式的完整性强制执行对业务来说不是问题
然后你可能会使用这样的方案来解决你的问题。