如果您有一位负责在实时环境中部署数据库的DBA，您会选择给他什么？他可以恢复到现有数据库的数据库创建脚本或备份？有哪些优点/缺点？ （我们正在使用MSSQL2000和MSSQL2005）
答案 0 :(得分：6)
我更喜欢用于部署的脚本，它们不那么具有侵入性。恢复将覆盖整个数据库，数据和所有，这对您的生产环境可能不是一个好主意..
答案 1 :(得分：5)
虽然我同意John关于使用数据库备份的第一次部署建议，但我更倾向于至少让脚本可供审阅，以便检查编码标准，性能评估等。
如果您正在寻找已经审核过的东西，那么备份/恢复对于第一次部署来说是一个完美的选择，如果在该数据库中有“暂存”的配置数据，则更是如此。这有助于避免冗长或复杂的插入语句。
一个超出第一个版本的特定版本将被编写脚本。在我们的环境中，我们需要发行说明来指定服务器，实例和脚本的路径。脚本应按数字顺序提供，由目标数据库分隔为文件夹，并使用第二组回滚脚本。我们甚至要求每个脚本在顶部都有一个USE语句，所以我们不必担心在master数据库中创建新对象！ ;）
答案 2 :(得分：3)
首次部署;数据库备份 ......它非常简单快捷。
如果数据库已经存在;它必须是一系列编号的脚本。就个人而言，我编写脚本编号，只通过脚本进行数据库更改。这可以确保所有数据库同步，或者可以非常简单地同步。
有些人认为这有点肛门......但我永远不会遇到生产部署问题。
答案 3 :(得分：1)
我不确定备份选项，但是使用db创建脚本，dba可以根据需要设置数据库（必须，权限等），然后用脚本创建表等。
答案 4 :(得分：1)
我更喜欢脚本，因为您可以将其放入存储库并跟踪它。您也可以非常轻松地在远程服务器上运行它。
答案 5 :(得分：1)
在源代码管理下使用脚本 - 一个可爱的好处是，您可以构建数据库中每个对象的可搜索历史记录，并且它是人类可读的。备份是黑盒子 - 您不知道它们将对您的数据库执行什么操作。
答案 6 :(得分：1)
绝对使用SQL脚本，因为它们可以受版本控制。最好将它们缩小并使用某种批次以已知的顺序（递增地）运行它们，这样就可以很容易地在已经生产的数据库中运行它们。
SQL脚本的替代方法是使用迁移框架。您可以在源代码中以小步骤指定数据库更改。迁移框架的好处是，不了解SQL的程序员可以简单地对数据库进行更改（但这并不需要了解某些数据库基础知识）。
他们对如何在增量步骤中构建和拆除数据库非常明确。这使得在不同版本的数据库系统或应用程序中测试和重新创建错误变得更加容易。
我所知道的迁移框架的一些例子是：
备份意味着实际备份数据库。随着数据库的增长，可移植性降低。所以程序员只需要一部分数据。出于安全原因，他们应该处理测试数据而不是真实数据。最好有一些测试数据生成器，以便开发人员和测试人员可以测试他们的实现，而不会损坏生产中的数据。
答案 7 :(得分：0)
数据库创建脚本更好 - 您可以随时打开记事本并进行修复。
答案 8 :(得分：0)
我会使用脚本 - 人类可读性，通过源代码控制的兼容性以及轻松处理数据库引擎升级的可能性，使我们能够在组织中实现这一目标。