Sql 我应该如何从；“坏的”；从数据库设计到可用设计？

我继承的当前项目主要围绕一个未规范化的表展开。虽然有一些标准化的尝试，但必要的约束没有落实到位

示例：在项目表中，有一个客户机名称（以及其他值），还有一个客户机表，它只包含客户机名称[没有任何键]。clients表仅用作添加新项目时向用户提供的值池。客户端表上没有主键或外键

这种“设计模式”在数据库的当前状态和使用它的应用程序中都很常见。我使用的工具有SQLServer2005、SQLServerManagementStudio和VisualStudio2008。我最初的方法是手动确定哪些信息需要规范化，并在查询中运行Select。有没有比逐案处理更好的方法，或者无论如何，这可以自动化

编辑：

---

此外，我还发现“工单编号”不是标识（自动编号，唯一）字段，它们是按顺序生成的，对每个工单都是唯一的。现有编号中也存在一些空白，但都是唯一的。编写存储过程以在迁移之前生成虚拟行，这是最好的方法吗？

我想不出一个明智的方法来自动化这个。。。。如果您希望输出有用，那么一些人工输入是此类重构的关键

重新工作订单编号；假设您希望它继续作为标识列；您是否可以填充数据，找到最大的数据，然后使用ALTER TABLE使其成为标识？不幸的是，我手头没有任何TSQL工具，因此无法进行测试。或者，把它看作是一个自然的键。

按照您认为的结构方式创建新数据库

在新数据库中创建一个importError表，其中包含“oldId”和“errorDesc”等列

编写一个简单、程序化、易读的脚本，尝试从旧结构中选择一行并将其插入新结构。如果插入失败，请尽可能将特定错误记录到importError表中（特别是插入失败的原因）

运行脚本

验证新数据。检查importError表中是否记录了错误。如果数据无效或存在错误，请重构脚本并再次运行，必要时可能会修改新的数据库结构

重复步骤1-5，直到生成实体转换脚本

此过程的结果将是您拥有： a） 一种新的数据库结构，该结构在旧结构的基础上进行了验证，并在“实用主义”的基础上进行了测试； b） 您可能需要针对其编写代码的潜在问题日志（例如，您无法通过转换来修复的错误，因为它们需要在您的模式中做出您不希望的让步）

---

（我可能会注意到，用您选择的脚本/编程语言编写脚本是有帮助的，而不是用SQL编写。）

迁移到可用设计的最佳方法是什么小心地

除非您愿意中断（并修复）当前使用数据库的每个应用程序，否则您的选择是有限的，因为您无法对现有结构进行太多更改

在你开始之前，仔细考虑你的动机——如果你有一个现存的问题（一个bug需要修复，一个增强需要进行），那么就慢慢来。然而，仅仅为了实现一个别人永远不会注意到的改进而在一个正常工作的生产系统上瞎搞是不值得的。请注意，这可能会对您有利—如果存在问题，您可以向管理层指出，最经济高效的修复方法是以这种方式更改数据库结构。这意味着您拥有对更改的管理支持，并且（希望）在出现问题时提供备份

一些实际的想法

一次只做一次更改。。。而只有一个变化。在继续之前，确保每个更改都是正确的。“量两次，割一次”这句古老的谚语是相关的

自动化。。。永远不要使用SQLServerManagementStudio“实时”更改生产系统。编写SQL脚本，一次性执行整个更改；根据数据库的副本开发并测试这些功能，以确保正确获取它们。不要将产品用作测试服务器-您可能会意外地对产品运行脚本；使用专用测试服务器（如果数据库大小小于4G，请使用在您自己的机器上运行的SQL server Express）

备份。。。任何脚本的第一步都应该是备份数据库，这样在出现问题时就可以返回

文档。。。如果有人在12个月后来找你，问你为什么他们的应用程序的X功能被破坏了，你需要一份数据库确切更改的历史记录，以帮助诊断和修复。第一个好的步骤是保留所有更改脚本

键。。。在数据库中抽象主键和外键，而不是通过应用程序显示，这通常是一个好主意。在业务层面上看起来像钥匙的东西（比如你的工作订单号）有一个令人不安的习惯，就是有例外。将键作为具有适当约束的附加列引入，但不要更改现有列的定义

---

祝你好运

我建议使用存储过程来帮助翻译过程

具体而言：

将代码中使用的查询逐个替换为存储过程。作为替换的一部分，直接针对存储过程编写单元（或集成）测试。考虑代码级<代码> SturdProps<代码>辅助类