Sql server SQL Server规范化/最佳做法：单个数据表

我从另一个部门的一位前雇员那里继承了数据库的维护工作，我相信他们的数据库开发技能并没有真正达到要求

我被要求支持或重建它

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

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

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

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

通过查看访问前端代码，每个字段、记录和字段的数据似乎都是通过搜索记录和字段，然后返回相应的字段和数据来存储的

---

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

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

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

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

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

---

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

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