每个表的许多未使用列的数据库设计注意事项具有相同的模式

Question

我是一名网络开发人员，所以我对数据库知之甚少。我最近加入的公司有一个非常成熟的桌面ERP，内置.NET和SQL Server，他们为大型企业客户提供服务，设计工作正常。但他们没有开发任何基于网络的系统。但是数据库设计很不寻常。让我解释一下，然后我会发布我的问题。

所以，现在我和他们一起开发了一个基于Web的ERP（Web中桌面系统的复制品）。由于我正在从头开始构建应用程序，因此我们可以自由地修改任何我认为会产生积极影响的事情。

现在的设计是，

• 他们在数据库中有大约150个表。
• 每个表都有相同的架构定义。
• 他们将这些领域分为三类。
  • 字符串（因此它们在数据库中分配50个varchar（250）字段。）
  • DateTime（因此他们在数据库中分配了15个smalldatetime字段）。
  • 数字（因此他们在数据库中分配30个数字（）字段。）
• 所有列的名称都是（这些名称不会吓坏开发人员，在一两周内他们习以为常，甚至记住许多字段关联）：
  • 字符串（S1，S2，S3，S4等）。
  • DateTime（D1，D2，D3，D4等）。
  • 数字（N1，N2，N3，N4等）。
• 正如我告诉你的架构。每个表由95列组成。实际上只使用 15-20列。其余75-80列为NULL。
• 表格标准化，维护索引。
• 大多数表格中的行数小于1000 。只有交易表记录接触数十万。
• 默认情况下，数字列的精度为（1,0）。当选择使用任何字段时，将根据要求调整精度。
• 空数据库大约为4MB。
• 这种设计使开发变得非常容易。因为他们有许多列，只要他们需要一个字段。它们只选择数据类型，即String或Numeric或DateTime，并分配下一个可用列。
• 只有9-10张表格有图像字段。

我认为这些信息已经足够了。现在我想问一下

• 因为，我不太了解SQL。这种设计对于Web环境是否可行（Web API将从Web客户端和移动设备调用）？
• 因为，每个表都有75-80个NULL列。当交易记录触及数百万时，它们将来会花费我们很多内存吗？ （考虑到申请是多租户）
• 您对改进此设计有何建议？

感谢。

Answer 1

您有两种选择：

1. 使用它，并与它一起生活。

2. 完全重新设计它。

我推荐＃1，因为＃2很难，你的同事和老板会怀疑地看待＃2。你进步的任何问题都将归结为你疯狂的数据库设计。

您描述的数据库体现了经典的实体 - 值 - 属性设计错误。设计人员选择从数据库中移除所有含义到应用程序，而不是定义在话语领域中的实际实体上建模的表，并使用DBMS来强制执行和推断它们之间的逻辑关系。应该在数据库中的实体使用应用程序逻辑在内存中构造，该应用程序逻辑为S1等提供意义。从数据库的角度来看，这绝对是一场噩梦。

这也是可以理解的。 EVA设计通常出现在数据库专业知识很少的地方，而且问题领域的理解很少。这加起来“任何东西都可以进入数据库”，EVA设计确实会有“任何东西”。在客户确定实际设计的程度 - 即每个数据库列的供应独立含义 - 应用程序充当一种DBMS代理。每个表都有大量未使用的列的事实表明它们的使用可能是由客户决定的：客户可以“添加一列”，并且应用程序从未使用的堆中提取一个。无需更改架构。这是动态！

整个行业都基于这个想法。例如，所谓的“主数据管理”工具归结为EVA设计，其中客户在应用程序中设计数据库，而应用程序以您描述的方式使用DBMS。