我正在着手一个相当复杂的项目，该项目最终将用于运行多个部门（人力资源，财务等）以及保存客户数据等。我已经获得了数据库设计文档，该文档解释了以前的人（不再在身边的人）如何设计数据库。这是我从未见过的设计。简化的想法是在表上保存实际数据，在第二张表上将数据组合成逻辑单元。
例如，这将是第一个包含数据的表：
KEY, DATA
0, Name
1, First Name
2, Last Name
3, Position
4, Title
5, Reports To
6, John
7, Smith
8, Developer
9, CTO
这是合并数据的第二张表：
KEY, GROUP_KEY, DATA_KEY, CHILD_KEY
0, NULL, 0, NULL
1, 0, 1, 2
2, 0, 2, NULL
3, NULL 3, NULL
4, 3, 4, 5
5, 3, 5, NULL
6, 0, 6, 7
7, 0, 7, NULL
8, 3, 8, 9
9, 3, 9, NULL
基本上，第二个表（键0）中的第一行定义了一个名为Name的新分组。接下来的两行定义了属于该组的“列”。第四行（键3）定义了另一个称为位置的分组，下面的两行再次定义了属于该组的“列”。最后四行将值John和Smith分配给Name组，将值Developer和CTO分配给Position组。
这大大简化了，但是我希望它给出了所建议的数据库结构的基本概念。一个表用于保存数据库中可能存在的所有可能值，第二个表将这些值组合为任何可能的组合。
我的新经理不太喜欢这种设计，就我个人而言，我从来没有遇到过这种设计。由于这将是一个使用Entity框架或NHibernate与数据库进行交互的C＃项目，因此这种数据库设计似乎对于在这两个框架中的任何一个实施都将是一个挑战。这种设计是否有名称，以便我进一步研究？此设计有哪些主要利弊？该文档提到这样做是为了获得更好的性能和“超级”规范化。
答案 0 :(得分：1)
这看起来像Inner-Platform antipattern。您已经有了RDBMS，而不是像将数据标准化为关系一样，而是决定像平面文件一样使用它并将每个数据转储到单独的行中，期望通过在运行时通过连接魔术键列将这些行组合为关系。
我从来没有见过这种效果很好；性能糟糕透顶，没有约束，因此数据到处都是丢失或重复，没有键关系，因此没有办法提高有效性，常规的数据库操作（如聚合和分组）必须使用过程逻辑手动完成。您基本上是在使用数据库来实现数据库。
您的建筑师可能认为他们提供了“可扩展性”。看！您可以将任何类型的任何数据添加到数据库的末尾！这很少有用。这使得查找数据和执行有效性几乎变得不可能。如果确实需要在运行时添加任何数据类型，那么自1970年代以来的每个SQL数据库都允许动态SQL并在运行时更改架构。
-1。不会再购买。