您是否将数据库静态数据放入源代码控制中？怎么样？

Question

我正在使用SQL-Server 2008和Visual Studio Database Edition.

使用此设置,保持模式同步非常简单.基本上,有一个"比较模式"工具,允许我将两个数据库和/或数据库模式的模式与源控制的创建脚本文件夹同步.

但是,就数据而言,情况不太清楚,数据可能有三种不同:

• 代码中引用的静态数据.典型示例:我的用户可以更改其设置,并将其配置存储在服务器上.但是,如果用户没有覆盖它,则每个设置都有一个系统范围的默认值.包含这些默认设置的表随着向程序添加更多选项而增长.这意味着在签入新功能/选项时,通常也会在数据库中创建系统范围的默认设置.

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

• 其他数据,即其他所有数据(日志,用户帐户,用户数据等)

我觉得我的第三个项目不应该是源代码控制的(当然,它应该定期备份)

但关于静态数据,我想知道该怎么做.

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

• 我(作为开发人员)如何警告执行部署的人员应该执行insert语句？

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

您如何管理数据库静态数据？

Answer 1

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

没有用于部署"当前"数据库架构的脚本.新版本通过所有中间版本(从版本1到当前版本)进行迭代.

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

• 我很容易测试新版本.我有以前版本的备份,我应用升级脚本,然后我可以恢复到以前的版本,更改脚本,再试一次,直到我对结果满意为止.
• 我的应用程序可以部署在任何以前的版本之上.各种客户端都有各种部署版本.升级时,我的应用程序支持从任何先前版本升级.
• 全新安装和升级之间没有区别,它运行相同的代码,因此我维护和测试的代码路径较少.
• DML和DDL更改之间没有区别(您的原始问题).他们都以同样的方式对待,因为脚本运行从一个版本更改为下一个版本.当我需要像您描述的那样进行更改(更改默认值)时,即使没有发生其他DDL更改,我实际上也会增加模式版本.所以在5.1版本中默认为'foo',在5.2中默认为'bar' ,这是两个版本之间的唯一区别,'upgrade'步骤只是一个UPDATE语句(当然后面是版本元数据更改) ,即.sp_updateextendedproperty).
• 所有更改都在源代码管理中,部分应用程序源(主要是T-SQL脚本).
• 我可以很容易地获得任何以前的架构版本,例如.重新调整客户投诉,只需运行升级序列并停止我感兴趣的版本即可.

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

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

Answer 2

我真的很喜欢你对三种类型数据的区分。

我同意第三个。

在我们的应用程序中，我们尽量避免首先放入数据库，因为它是重复的（因为它必须在代码中，所以数据库是重复的）。第二个好处是我们不需要连接或查询就可以从代码中访问该值，因此这可以加快速度。

如果我们希望在数据库中包含其他信息，例如，如果可以根据客户站点更改该信息，我们会将两者分开。其他表仍然可以引用该数据（通过索引例如：0、1、2、3 或通过代码例如：EMPTY、SIMPLE、DOUBLE、ALL）。

对于第二个，脚本应该处于源代码管理中。我们将它们与结构分开（我认为它们通常会随着时间的推移而被替换，而结构会不断添加增量）。

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

我们有一个完整的程序，每个版本都附带一个自述文件，其中包含脚本等等......