我继承的当前项目主要围绕一个非标准化表.有一些尝试正常化,但没有实施必要的限制.
示例:在Project表中,有一个客户端名称(以及其他值),还有一个客户端表,它只包含客户端名称[无任何键在任何地方].clients表仅用作值池,以便在添加新项目时为用户提供.客户端表或外键上没有主键.
诸如此类的"设计模式"在数据库的当前状态和使用它的应用程序中很常见.我可以使用的工具是SQL Server 2005,SQL Server Management Studio和Visual Studio 2008.我最初的方法是手动确定哪些信息需要规范化并运行Select INTO查询.有没有比个案更好的方法,或者无论如何这可以自动化？
编辑: 此外,我发现"工单号"不是IDENTITY(自动编号,唯一)字段,它们是按顺序生成的,对每个工单都是唯一的.现有编号也存在一些差距,但都是独一无二的.这是编写存储过程以在迁移之前生成虚拟行的最佳方法吗？
迁移到可用设计的最佳方法？小心
除非您愿意打破(并修复)当前使用数据库的每个应用程序,否则您的选项会受到限制,因为您无法更改现有结构.
在开始之前,请仔细考虑您的动机 - 如果您有现有问题(要修复的错误,要做的改进),请继续进行.然而,为了实现其他任何人都不会注意到的改进,使用一个正常工作的生产系统是很有价值的.请注意,这可能对您有利 - 如果存在问题,您可以向管理层指出,解决问题的最具成本效益的方法是以这种方式更改数据库结构.这意味着您可以获得对更改的管理支持 - 并且(希望)如果某些内容变成了梨形状,则可以进行备份.
一些实际的想法......
一次进行一次更改 ...... 只进行一次更改.在继续之前确保每个更改都是正确的."两次测量,一次切割"的古老谚语是相关的.
Automate Automate Automate ...永远不要使用SQL Server Management Studio对生产系统进行"实时"更改.编写一次性执行整个更改的SQL脚本; 根据数据库的副本开发和测试这些,以确保您正确使用它们.不要将生产用作测试服务器 - 您可能会意外地针对生产运行脚本; 使用专用的测试服务器(如果数据库大小低于4G,请使用在您自己的盒子上运行的SQL Server Express).
备份 ......任何脚本的第一步都应该是备份数据库,以便在出现问题时你可以回过头来.
文档 ...如果有人在十二个月内找到您,询问为什么他们的应用程序的功能X被破坏,您将需要有关数据库的确切更改的历史记录,以帮助诊断和修复.第一个好的步骤是保留所有更改脚本.
密钥 ......通常一个好主意是在数据库中保持主键和外键的抽象,而不是通过应用程序显示.在业务层面看起来像钥匙的东西(比如你的工作订单号)有一个令人不安的例外习惯.将您的密钥作为具有适当约束的附加列引入,但不要更改现有密钥的定义.
祝好运!
京公网安备 11010802040832号 | 京ICP备19059560号-6 