代码之家  ›  专栏  ›  技术社区  ›  CleverPatrick

将数据库更新部署到生产数据库的最新技术是什么?

  •  4
  • CleverPatrick  · 技术社区  · 15 年前

    我工作过的每一家商店都有自己的拼凑、随意、不易理解和维护的更新生产数据库的方法。

    我从来没有见过一个一致的方法来做这件事。

    所以,在最新版本的SQL Server中, 更新模式更改和将数据从开发或测试服务器迁移到生产服务器的最佳实践是什么?

    我想最终的工具能够

    • 检测两个数据库之间的架构更改并生成DDL以将一个数据库更新到另一个数据库。
    • 包括具有执行自定义数据迁移步骤的自定义代码的能力
    • 允许版本控制,以便v1 db可以一直更新到v99数据库,按顺序运行所有脚本和迁移步骤。
    4 回复  |  直到 15 年前
        1
  •  2
  •   Daveo    15 年前

    对于小项目,我使用RedGate管理模式和数据迁移,取得了很多成功。在大多数情况下都很容易使用。

    对于用于架构和数据更改的大型企业系统,通常将所有SQL脚本保存为文本文件并运行它们。我们还提供了一个回滚脚本,以便在迁移过程中出错时运行。在UAT服务器上运行此命令,然后在生产服务器上运行Test/staging/pre prod server。保存所有这些文件的副本以及它们的回滚脚本应该允许您从一个数据库的多个版本移动。

    还有 http://code.google.com/p/migratordotnet/

        2
  •  3
  •   Chris Gomez    15 年前

    我用过的三件事是:

    对于架构

    红门的SQL比较和整个SQL工具带。他们已经非常努力地使这个东西你可以版本控制。在实践中,我发现对于数据库,您通常试图从版本时间线中的点A到点B。对于二进制文件,您通常只需删除点B中的任何内容(我知道这是一个过于简单化的过程,但通常是正确的)。

    http://www.red-gate.com/

    如果您的系统很小,而且可能会一直很小,那么xSQL是一个很好的起点:

    http://www.xsqlsoftware.com/LiteEdition.aspx

    我不为这些人工作,也不认识为他们工作或从他们那里得到钱的人。告诉你我过去做过什么。

    对于数据

    红门有SQL数据比较。

    但是,如果您想要“免费”的东西(或者包括在SQL Server中)

    BCP摘录的问题是它们的版本控制不是很好。我使用了一些技巧,比如在字符模式下提取并在提取查询中填充order by,以尝试按某种顺序提取行,使它们更适合版本控制。

        3
  •  2
  •   Remus Rusanu    15 年前

    首先,您必须认为场景之间的需求是不同的 很多 :

    1. 客户在好市多购买v1产品,并将其安装在家庭办公室或小型企业中。当v2发布时,客户购买一盒产品并将其安装到新计算机上。它从v1安装导出数据并将其导入到v2安装。即使v1和v2在后台都使用SQL Express实例,也不支持升级。不需要对部署的数据库(隐藏数据库、非技术用户)进行架构更改,也绝对不支持。唯一支持的“升级”路径是显式导出/导入,它可能使用XML文件或类似文件。

    2. 企业通过支持合同购买产品的v1。它将其安装在其部门SQL Server实例上,从中购买的产品可以访问数据 通过更多的集成服务、报告等。当v2发布时,客户运行指定的升级过程,如果遇到问题,则调用产品供应商客户支持热线,该热线引导客户完成其部署的某些特定步骤。数据库模式定制是预期的,并且经常得到支持,包括升级场景,但是模式更改是由客户完成的(在v2设计时不知道)。

    3. 一个web启动有一个支持该站点的数据库。开发人员对其个人实例进行更改并签入更改。具有连续集成的自动生成部署将获取更改并将其部署到测试实例上,并运行生成验证测试。主分支构建可以随时部署到生产环境中。生产是 这个 一个支持站点的数据库。生产数据库的结构被100%地记录和理解,生产数据库模式的每一个变更都是通过构建系统和QA过程发生的。另一方面,这是最让提出问题的用户记住的场景,减去“100%记录和理解”部分。我举了WWW支持网站的例子,但是解聚可以是任何东西。其要点是只有一个生产数据库(它可能包含HA/DR副本,并且可能包含多个实际的SQL Server数据库),并且 只有 必须升级的数据库。

    4. 一个 网络启动。同上,但生产数据库有5TB的数据和5分钟的停机时间成为CNN的头条新闻。架构更改可能涉及设置副本和将数据复制到具有连续更新的新架构中,然后将操作联机切换到副本。模式更改由MCM专家设计,部署模式更改可以是一个多周的过程。

    我可以继续讲更多的情节。关键是,每一个案例的要求都大不相同,没有一个“最先进的”能够回答所有这些问题。使用schema diff部署工具(如 vsdbcmd SQL Compare . 其他场景将更好地面对显式 versioning scripts . 另一个可能有这样的特定要求(例如0停机时间),每个升级都是一个独立的项目,必须专门定制。

    但有一件事是很清楚的:如果你的商店威胁到开发数据库 *作为“源”,并使用管理工具对其进行更改,即 总是 少校 #fail . 所有更改都应该作为某种源代码管理工件显式捕获,这就是为什么我喜欢大多数显式版本脚本,如 Version Control and your Database . 但是我再次确认VSDB项目对编译时模式验证的支持以及它对模式对象的重构的方便性使它成为一个非常强大的命题,VSDB模式比较部署 可以

    另一个需要解决的重要方法是从EF或LinqToSql等工具进行代码优先的模式建模。它可以很好地部署v1,但在随后的任何版本中都会失败。我强烈反对这些做法。

    但总结一下,简单回答一下:就像今天一样,技术水平很差。

        4
  •  1
  •   David Atkinson    15 年前

    在红门,我们会根据您的需求和您需要的流程的正式程度,推荐两种方法之一。如果您有一个开发数据库,并且只想将更改推送到生产环境中,那么SQL Compare就是该作业的工具。使用架构快照可以实现一定级别的版本控制。

    SQL Source Control . 这将开发数据库链接到Team Foundation Server或Subversion。