sql - 您是否将数据库静态数据放入源代码控制中？如何？

Question

我正在使用带有 Visual Studio 数据库版的 SQL-Server 2008。

使用此设置，保持架构同步非常容易。基本上，有一个“比较架构”工具允许我将两个数据库的架构和/或数据库架构与源代码控制的创建脚本文件夹同步。

然而，当涉及到数据时，情况就不太清楚了，它可以是三种不同的类型:

代码中引用的静态数据 .典型示例:我的用户可以更改他们的设置，并且他们的配置存储在服务器上。但是，每个设置都有一个系统范围的默认值，以防用户没有覆盖它。随着更多选项被添加到程序中，包含这些默认设置的表格会增加。这意味着当 checkin 新功能/选项时，通常也会在数据库中创建系统范围的默认设置。

静态数据 .例如。填充下拉列表的产品列表。该程序不依赖于列表中特定产品的存在来工作。例如，这可以是在部署程序的新“unicode 版本”时应在生产中部署的 unicode 编码产品列表。

其他数据 ，即其他所有内容(日志、用户帐户、用户数据等)

在我看来，我的第三个项目不应该是源代码控制的(当然，它应该定期备份)

但是关于静态数据，我想知道该怎么做。

我应该将插入脚本附加到创建脚本吗？或者也许使用单独的脚本？

我(作为开发人员)如何警告进行部署的人员他们应该执行插入语句？

我应该区分我的两种数据吗？ (第一个通常由开发人员创建，而第二个通常由非开发人员创建)

你如何管理你的数据库静态数据？

Answer 1

我已经解释了我在博客中使用的技术 Version Control and Your Database .我使用数据库元数据(在本例中为 SQL Server 扩展属性)来存储部署的应用程序版本。我只有从一个版本升级到另一个版本的脚本。在启动时，应用程序从数据库元数据中读取已部署的版本(缺少元数据被解释为版本 0，即尚未部署任何内容)。对于每个版本，都有一个应用程序功能可以升级到下一个版本。通常，此函数运行执行升级的内部资源 T-SQL 脚本，但也可以是其他的，例如在数据库中部署 CLR 程序集。

没有用于部署“当前”数据库模式的脚本。新的分期付款会遍历所有中间版本，从版本 1 到当前版本。

我喜欢这种技术有几个优点:

我很容易测试新版本。我有以前版本的备份，我应用了升级脚本，然后我可以恢复到以前的版本，更改脚本，再试一次，直到我对结果满意为止。

我的应用程序可以部署在任何以前的版本之上。不同的客户端有不同的部署版本。当他们升级时，我的应用程序支持从任何以前的版本升级。

全新安装和升级之间没有区别，它运行相同的代码，因此我需要维护和测试的代码路径更少。

DML 和 DDL 更改之间没有区别(您的原始问题)。它们都以相同的方式处理，因为脚本运行以从一个版本更改为下一个版本。当我需要像您描述的那样进行更改(更改默认值)时，即使没有发生其他 DDL 更改，我实际上也会增加架构版本。所以在 5.1 版本中默认是 'foo'，在 5.2 中默认是 'bar'，这是两个版本之间的唯一区别，而 'upgrade' 步骤只是一个 UPDATE 语句(当然之后是版本元数据更改，即 sp_updateextended 属性)。

所有更改都在源代码控制中，是应用程序源代码的一部分(主要是 T-SQL 脚本)。

我可以轻松访问任何以前的架构版本，例如。重现客户投诉，只需运行升级序列并停止在我感兴趣的版本。

这种方法多次拯救了我的皮肤，我现在是一个真正的信徒。只有一个缺点:在源代码中没有明显的地方可以找到“程序 foo 的当前形式是什么？”。因为最新版本的 foo 可能在 2 或 3 个版本之前已经升级，并且此后没有更改，所以我需要查看该版本的升级脚本。我通常只查看数据库并查看其中的内容，而不是搜索升级脚本。

最后一点:这实际上不是我的发明。这是完全按照 SQL Server 自身升级数据库元数据 (mssqlsystemresource) 的方式建模的。