大型项目的两表数据库设计

Question

我正在开始研究一个相当复杂的项目，该项目最终将用于运行多个部门（人力资源，财务等）以及保存客户数据等。我已经交了一个数据库设计文档，解释了之前的情况个人（不再在身边）想要设计数据库。这是我以前从未遇到过的设计。简化的想法是，表上有实际数据，第二个表将数据组合成逻辑单元。

例如，这里将是第一个包含数据的表：

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）定义另一个名为Position的分组，并且以下两行再次定义属于该组的“列”。最后四行将值John和Smith“分配”到组名称，并将值Developer和CTO分配给组Position。

这大大简化了，但我希望它提供了所提出的数据库结构的基本概念。一个表用于保存数据库中可能存在的所有可能值，另一个表用于将这些值组合成任何和所有可能的组合。

我的新经理对这个设计并不太热衷，我个人从来没有碰过它。由于这将是一个使用Entity框架或NHibernate与数据库交互的C＃项目，这种数据库设计似乎在这两个框架中实现都是一个挑战。这种设计有名称，所以我可以进一步研究吗？这个设计有什么重大的优点或缺点吗？该文档提到这样做是为了获得更好的性能和“超级”规范化。

Answer 1

这看起来像Inner-Platform antipattern。你有一个RDBMS，而不是将数据规范化为关系，你决定像平面文件一样使用它，并将每个数据转储到一个单独的行中，期望通过连接魔术键列在运行时将行组合成关系。

我从未见过这项工作;性能很糟糕，没有约束因此数据在整个地方丢失或重复，没有关键关系因此无法强制执行有效性，聚合和分组等正常的数据库操作必须使用过程逻辑手动完成。您基本上使用数据库来实现数据库。

您的架构师可能认为他们提供了“可扩展性”。看！您可以将任何类型的数据添加到数据库的末尾！这很少有用;它使得查找数据和执行有效性几乎不可能。如果您确实需要在运行时添加任何数据类型，那么自20世纪70年代以来的每个SQL数据库都允许动态SQL并在运行时更改模式。

-1。不会再购买。