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

问题描述 投票:0回答:1

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

例如,这里将是第一个包含数据的表:

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#项目,这种数据库设计似乎在这两个框架中实现都是一个挑战。这种设计有名称,所以我可以进一步研究吗?这个设计有什么重大的优点或缺点吗?该文档提到这样做是为了获得更好的性能和“超级”规范化。

c# database database-design database-normalization
1个回答
1
投票

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

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

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

-1。不会再购买。

© www.soinside.com 2019 - 2024. All rights reserved.