SQL Server 规范化/最佳实践：单一数据表答案

【问题标题】：SQL Server Normalisation/Best Practices: Single Data TableSQL Server 规范化/最佳实践：单一数据表
【发布时间】：2011-12-30 04:05:18
【问题描述】：

我从另一个部门的前雇员那里继承了对数据库的维护工作，我认为他们的数据库开发技能确实达不到标准。

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

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

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

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

还有另外两个表可以识别记录（由等创建）和字段（更新日期，字段数据类型）的详细信息

查看 Access 前端代码，似乎每个字段和记录和字段的数据都是通过搜索记录和字段来存储的，然后将相应的字段与数据一起返回。

我的问题：这样做的目的是什么，或者这种类型的开发是否被认为是没有经验的数据库开发人员的工作？

【问题讨论】：

基本上很难回答。没有看到应用程序的要求、结构和细节，没有人能真正说出为什么选择这种数据库设计。

标签： sql-server types normalization

【解决方案1】：

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

我会开始问的问题（你自己、任何程序员、DBA、项目经理等）：

当时的需求是否如此抽象以至于无法创建具有数据关系的正式模式？（坏，坏，坏）
数据库设计师是懒惰还是缺乏经验？
程序员是懒惰还是缺乏经验？（更好的是，程序员是 DBA 吗？）
数据的可靠性/可用性是否如此敏感，以至于很难定期进行正式的架构更改？
该项目是否在您之前经历了很多人只是继承了问题，而这是一个 hack 解决方案？（虽然最初的程序员可能知道它最终打算去哪里......）

我认为您在这里真正想表达的是“这行得通，还是我应该改变它？”。如果任何读取/搜索查询都得到优化，我会感到震惊，因为这种任意数据存储不可能有任何索引。如果应用程序只是简单地记录信息，它可能没什么大不了的，因为发起者可能只是还不知道以后如何使用数据，并编写一个一次性小程序来循环并创建从数据中取出正式的对象会比一开始就假设一切要好。

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

【讨论】：

数据库是在我们的 IT 部门一无所知的情况下开发的，因此我现在继承了该应用程序。深入研究数据库的逻辑，似乎有几个具有不同字段集的 Access 表单与这个表挂钩。
数据库是在没有任何 IT 知识的情况下设计的，这里需要。我假设这个人参加了一个简短的 Access/VBA 课程，并认为自己是“专家”。基本上，它是一个为财务部门记录不同类型数据的数据输入日志应用程序。
每个都形成一组不同的未绑定的最多 100 个控件字段和一个“维护”屏幕，以将这些控件链接到记录并将字段返回到数据库。我担心的是长期生存能力和性能，准确地说是 893,135 条记录。我现在必须支持它，有人问我是否可以选择重新开发。我的问题是：这种单一的“紧凑”结构是否适合数据输入/检索？它达到什么目的？每条记录需要返回 100 多条记录，而不是结构化表中的 1 条记录。但是，一个长 100+ 会有性能问题吗？
毫无疑问是的。尝试使用其中一个读取查询运行“EXPLAIN EXTENDED”（只需将这两个词放在“SELECT”之前），我猜你会看到一长串临时表和/或文件排序。您有可以在这里展示的示例 sql 查询吗？
抱歉，我忘记了您问题的第 1 部分。不，除了在应用程序端抽象逻辑之外，这对任何事情都没有好处，这样您就不必每次会计部门询问“嘿，我可以在...上运行报告吗？”时创建新表并编写新查询。