SQL Server标准化/最佳实践:单一数据表

Question

我从另一个部门的前雇员那里继承了数据库的维护工作，我相信他们的数据库开发技能并不是很好。

我被要求支持或重新开发它。

似乎每条记录的数据数据库都在一个表中，是的，我知道，并且有数十万行的空字段。

TableData:
> RowID
> FieldID
> DateData
> NumberData
> TextData
> YesNoData

在此实例中，对于每一行，似乎只填充了一个字段(取决于所需的数据类型)，其余字段均为空。

还有另外两个表，用于标识记录(由etc创建)和字段(更新日期，字段数据类型)的详细信息

查看Access前端代码，您会发现每个字段和记录的数据都是通过搜索记录和字段，然后返回包含数据的适当字段来存储的。

我的问题是:这是为了什么目的，或者这种类型的开发被认为是缺乏经验的数据库开发人员的工作？

Answer 1

我最好的猜测是，像这样的表用于存储任意数据(从其他支持表推断)，这些数据不需要更改模式即可存储“未计划的”或尚未在应用程序的业务逻辑中实现的信息。

我首先要问的问题(您自己、任何程序员、DBA、项目经理等)：

• 当时的需求是否如此抽象，以至于不可能创建具有数据关系的正式模式？(糟糕，糟糕，糟糕)
• 是数据库设计师懒惰，还是inexperienced?
• Was程序员懒惰，还是缺乏经验？(更好的是，程序员是数据库管理员吗？)
• 数据的可靠性/可用性是如此敏感，以至于很难定期进行正式的模式更改？
• 在您之前经历了很多人，他们只是简单地继承了问题，这是一个黑客解决方案吗？(虽然最初的程序员可能知道它的目标是eventually...)

我认为你真正想要的是“这行得通吗，或者我应该改变它吗？”如果任何读取/搜索查询都被优化了，我会感到震惊，因为不可能有任何索引来存储这种任意的数据。如果应用程序只是记录信息，这可能不是什么大问题，因为创建者可能只是还不知道数据稍后将如何使用，并且编写一个一次性的applet来循环遍历数据并从数据中创建正式对象将比试图一开始就假设一切都要好。

更有针对性的是，您是否因为这个特定的表而在流程中遇到了瓶颈，或者只是出于惊讶而担心？如果是前者，我会想办法马上改变它。如果是后者，我会花时间先弄清楚应用程序的长期需求。