我非常喜欢你区分三种类型的数据。 我同意第三个。 在我们的应用程序中，我们尽量避免首先放入数据库，因为它是重复的(因为它必须在代码中，数据库是重复的)。第二个好处是我们不需要连接或查询来从代码中访问该值，因此这样可以加快速度。

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

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

在开发CMS系统时我遇到过这种情况。 我将静态数据(代码中引用的内容)附加到数据库创建脚本，然后添加一个单独的脚本以添加任何“初始化数据”(如国家，初始产品群等)。

对于前两个步骤，您可以考虑对数据使用中间格式(即XML)，然后使用自行开发的工具或CodeSmith之类的东西来生成SQL，以及可能的源文件，如果(例如)你具有与代码中使用的枚举相关的查找表 - 这有助于实现一致性。 这有另一个好处，如果架构发生更改，在许多情况下您不必重新生成所有INSERT语句 - 您只需更改工具即可。

请参阅。来自前两点的静态数据应该在源控制中，恕我直言。 编辑：*新

• 如何确保他们执行它：好吧，在应用程序/数据库部署文档中再迈一步。如果您在数据库中推出真正需要特定(新)静态数据的应用程序，那么您可能希望在应用程序中执行数据库版本检查。并将DB_VERSION更新为新版本号，作为该脚本的一部分。然后，如果需要新的数据库版本，启动时的应用程序应检查并报告错误。
• dev和非dev静态数据：我从未见过这种情况。更常见的是真实的静态数据，您可以称之为“dev”，这是主要配置，ISO静态数据等。另一种类型是默认查找数据，供用户使用，但它们可能会添加更多。 INSERT这些数据的机制可能有所不同，因为您需要确保不会对用户创建的数据进行驱动(强制)。

首先，我从未使用过Visual Studio Database Edition。使用此实用程序为您提供的任何工具，您都是幸运的(或被诅咒的)。希望这包括很多灵活性。 我不知道我会在你的1型和2型静态数据之间做出很大的改变。两者都是定义一次然后从未更新的数据集，除非后续版本和更新，对吧？在这种情况下，主要区别在于数据是如何或为何原样，而不是如何存储或初始化数据。 (除非数据是特定于环境的，如“A”表示开发，“B”表示生产。这将是“类型4”数据，我将在这篇文章中高兴地忽略它，因为我已经使用SQLCMD解决了它变量，他们让我头疼。) 首先，我将创建一个脚本来创建数据库中的所有表 - 最好只有一个脚本，否则你可以有很多脚本(当重命名列时查找和替换变得非常笨拙)。然后，我会创建一个脚本来填充这些表中的静态数据。此脚本可以附加到表脚本的末尾，或者使其成为自己的脚本，甚至可以为每个表创建一个脚本，如果要加载数百或数千行，这是一个好主意。 (有些人制作一个csv文件，然后发出一个BULK INSERT，但我会避免这只是给你两个文件和一个复杂的过程[在部署时配置驱动器映射]来管理。) 要记住的关键是数据(存储在数据库中)可以并且将随着时间而改变。很少(如果有的话)你会有幸删除你的生产数据库，并用一个新的，有光泽的新数据库替换它，没有过去无数年来所有那些狡猾的数据。数据库都是关于随时间的变化，而这正是脚本自成一体的地方。您可以从脚本开始创建数据库，然后随着时间的推移添加修改数据库的脚本 - 这也适用于您的静态数据(任何类型)。 (最终，我的方法类似于会计：你有账户，随着变化的到来你用日记账分录调整账户。如果你发现你犯了错误，你永远不会回去修改你的参赛作品，你只需要做一个后续的参赛作品反转并修复它们。这只是一个类比，但逻辑是合理的。)

我使用的解决方案是在源代码管理中创建和更改脚本，以及存储在数据库中的版本信息。 然后，我有一个安装向导，可以检测是否需要创建或更新数据库 - 通过根据数据库中存储的版本信息选择适当的脚本来管理更新过程。

如果要更改静态数据(将新项添加到用于生成下拉列表的表)，则插入应位于源代码控制中并与其余代码一起部署。如果需要插入其余代码才能工作，则尤其如此。否则，在部署代码时可能会忘记此步骤，并且不会发生这么好的事情。 如果静态数据来自其他来源(例如在美国导入当前机场代码)，那么您可能只需要运行已经记录的导入过程。导入过程本身应该在源代码控制中(我们使用所有SSIS包执行此操作)，但数据不必是。

在Red Gate，我们最近在SQL Data Compare中添加了一个功能，允许将静态数据存储为DML(每个表的一个.sql文件)以及SQL Compare当前支持的模式DDL。 要了解其工作原理，将解释其工作原理。 我们的想法是，当您想要将更改推送到目标服务器时，可以使用脚本作为源数据源进行比较，从而生成必要的DML同步脚本以更新目标。这意味着您不必假设每次都从头开始重新创建目标。我们希望在即将推出的中支持静态数据。 Red Gate Software产品经理David Atkinson

我已经解释了我在博客中使用的技术。我使用数据库元数据(在本例中为SQL Server扩展属性)来存储已部署的应用程序版本。我只有从版本升级到版本的脚本。在启动时，应用程序从数据库元数据中读取已部署的版本(缺少元数据被解释为版本0，即尚未部署任何内容)。对于每个版本，都有一个应用程序功能，可以升级到下一个版本。通常，此函数运行执行升级的内部资源T-SQL脚本，但它可能是其他内容，例如在数据库中部署CLR程序集。 没有用于部署“当前”数据库架构的脚本。新版本通过所有中间版本(从版本1到当前版本)进行迭代。 我喜欢这种技术有几个优点：

• 我很容易测试新版本。我有以前版本的备份，我应用升级脚本，然后我可以恢复到以前的版本，更改脚本，再试一次，直到我对结果满意为止。
• 我的应用程序可以部署在任何以前的版本之上。各种客户端都有各种部署版本。升级时，我的应用程序支持从任何先前版本升级。
• 全新安装和升级之间没有区别，它运行相同的代码，因此我维护和测试的代码路径较少。
• DML和DDL更改之间没有区别(您的原始问题)。他们都以同样的方式对待，因为脚本运行从一个版本更改为下一个版本。当我需要像您描述的那样进行更改(更改默认值)时，即使没有发生其他DDL更改，我实际上也会增加架构版本。所以在版本5.1中默认为'foo'，在5.2中默认为'bar'，这是两个版本之间的唯一区别，'upgrade'步骤只是一个UPDATE语句(当然后面是版本元数据更改)
• 所有更改都在源代码管理中，部分是应用程序源(主要是T-SQL脚本)。
• 我可以轻松访问任何以前的架构版本，例如。重新调整客户投诉，只需运行升级顺序并停在我感兴趣的版本上。
UL> 这种方法多次拯救了我的皮肤，现在我是一个真正的信徒。只有一个缺点：没有明显的地方可以在源头查找'当前形式的程序foo是什么？'。因为最新版本的foo可能已经升级了2或3个版本并且之后没有更改，所以我需要查看该版本的升级脚本。我通常只是查看数据库并查看其中的内容，而不是搜索升级脚本。 最后一点：这实际上不是我的发明。这完全是在SQL