升级现有数据库时的最佳做法问题。假设将对数据本身进行各种修改，结构，关系，附加列，消失的列等等。
我的问题很简单。我正在开发一个将使用SQL Server的项目。没问题，因为我已经足够专家来处理这个问题了。但是这个项目将在稍后升级，我需要指定升级机制需要遵循的协议。基本上，在创建升级脚本时需要遵循此协议...
现在，我有以下简单的步骤：
不知何故，这个清单感觉不完整。是否有更多的扩展列表描述了升级过程中需要遵循的正确步骤？
此外，是否始终可以在单个数据库事务（使用SQL Server）中进行完整升级，或者是否需要在协议中包含断点，其中一个事务应该结束而另一个事务应该开始？
系统不包含任何存储过程或其他“特殊”功能。数据库只是：一个数据存储，只有表和它们之间的关系。没有角色，没有用户，没有存储过程，没有触发器，没有复杂的数据类型...
在开发期间，所有开发人员都使用他们自己的数据库实例，他们可以完全控制它们。由于我们不是使用该应用程序的人，因此我们倾向于为Express版本开发，而不是更昂贵的版本。说实话，我们不开发我们的应用程序来支持很多用户，但我们会通知我们的用户，因为它使用SQL Server，他们可以根据自己的需要在更大的SQL Server平台上安装系统。不过，他们需要自己的DBA。我们有一个更大的SQL Server可用于我们自己，我们也用于我们自己的Web界面，但是这个服务器位于一个特殊的数据服务器中，在那里为我们而不是我们维护它。
该项目以前使用MS Access进行数据存储，并且用于单用户开发，但事实证明，许多用户仍然决定共享他们的数据库，这表明数据模型本身足够可靠，可用于多个用户。用户环境。因此，我们迁移到SQL Server以支持具有3个或更多用户的小型办公室以及将同时拥有500个或更多用户的一些大型组织。
由于我们需要将软件的成本保持在较低水平，因此我们没有足够的预算来支付昂贵的工具或更昂贵的服务器。
答案 0 :(得分：4)
查看Red-Gate的SQL Compare（结构比较），SQL Data Compare（数据比较）和SQL Packager（用于将更新脚本打包成C＃项目或.NET可执行文件）
它们为您的所有数据库升级需求提供了一个漂亮，干净，功能齐全且易于使用的解决方案。他们非常值得他们的许可证费用 - 在几周或几个月内收回成本。
强烈推荐！
答案 1 :(得分：2)
在我看来，这是一个绝对的熊手动做这些。对于Microsoft SQL Server，我建议使用Team System的数据库编辑，因为它包含数据库的完整源代码控制功能，并且可以自动构建脚本以升级/降级版本。
另一个选项是带有Redgate的SQLCompare，它还可以处理这些类型的升级/降级，并将产生一个非常好的SQL脚本。我已经使用过两者，保留历史脚本有助于我们解决问题并解决许多谜团。
如果您正在使用上述手动脚本，请不要忘记在脚本中考虑SP更改。此外，任何手动编辑的脚本都应该能够在数据库上多次执行 - 即如果您的脚本包含表创建或删除，请务必先检查是否存在，否则如果背靠背执行您的脚本将失败。 / p>
同样，虽然可以构建一个手动协议，但我仍然会使用其中一个专用工具，并且Team System和SQL Compare都能够输出您可以包含的脚本作为一部分安装/升级包。
答案 2 :(得分：1)
随着数据库更新，我始终认为它应该是全部或全部。如果任何数据库更新失败，您的应用程序将处于可能对数据有害的未知状态，因此我认为最佳实践是全部应用或不应用（围绕它们全部执行1个事务）。
我还想在应用更新之前备份数据库，这样如果出现任何问题，数据库就可以回滚了（这在处理实时数据时已经多次保存了。）
希望这有帮助。
答案 3 :(得分：1)
升级生产数据库架构的最佳做法实际上看起来非常糟糕。除非您可以完全关闭系统以进行升级，这通常是不可能的，否则您的更改都需要向后兼容。如果有许多客户端访问数据库，则无法同时更新它们，因此您所做的任何架构更改都需要允许旧代码运行。
这意味着永远不要重命名列，并使所有新列都可以为空。这并不意味着你永远留下它。您编写了两个脚本，一个用于初始更改，一个向后兼容，另一个用于在所有客户端更新后清理。
自动化工具非常适合验证模式，但在实际修改复杂系统时它们并不是那么好。您应该将更改分解为许多小的，离散的更改脚本，以便每个都可以手动运行。如果出现故障，则更容易确定原因并进行修复。基本上，每个功能都有自己的脚本。为每个人提供一个唯一的名称，然后在运行脚本时将该名称存储在数据库中，这样您就可以查询数据库以找出已运行的内容和未运行的内容。当您在开发人员的计算机，测试服务器，生产等上有实例时，这是非常宝贵的。