应用错误收集

我处理的是一个包含许多表，视图和存储过程的软件。目前，为了使开发人员能够轻松地在其本地数据库上运行所有最新更新，并且为了便于部署软件，我们有一个大型Update.sql文件。这将创建不存在的表和存储过程，并添加/更新/删除需要更改的数据。它被设计为一次又一次地运行而不会弄乱某些数据库，只应用所需的更改。这对开发人员和部署非常方便。

但是，我真的很想能够将所有数据库对象（表，函数，存储过程，回填/数据更新）拆分为源代码管理中的单独脚本。这将允许我们跟踪对单个数据库对象的更改，而不仅仅是一个大型SQL文件。

有没有一种方法可以充分利用两个世界？也许是一个免费工具，可以运行文件夹及其所有子文件夹中的所有SQL文件？或者是一些批处理脚本，可以在每次签入后将所有单个文件合并到一个文件中？

编辑10/27/2017：在回顾了答案分享的一些链接之后，我认为这个问题归结为找到一种方法来采用基于状态的VS迁移的数据库更新管理的最佳部分。 Here is an article我认为很好地分解了差异和利弊，但我总结了下面我关注的部分

基于状态：这是Visual Studio SQL Server项目使用的内容。它是数据库在当前版本中应该是什么样子的快照。通过将数据库与此快照进行比较以及将自动生成将改变表/视图/ SP /等的脚本来创建对服务器的更新。成为他们需要的。

优点：

版本控制：每个数据库对象（表，存储过程等）都是一个单独的脚本文件。这使得跟踪对这些对象的更改随着时间的推移变得非常易于管理，因为您只能查看源控件历史记录。
编译：如果您使用的是Visual Studio SQL Server项目，您实际上可以编译它们，它们会告诉您引用是否都很好。例如，如果删除表中的列并且存在引用该列的存储过程，则会告诉您SP引用了不再存在的列，因此您可以对其进行修复。
简单部署：您可以使用具有数百个单独数据库对象脚本的这些项目，并使用Publish或通过编译它并将其对SQL进行的DacPac更新为数据库来更新数据库。因此，即使有一堆单独的文件，在编译之后，它也会归结为最终使用的一个文件。

缺点：

更新数据：在现实世界中，基于状态的更新通常是不可行的。例如，假设您的“联系人”表格曾用于“全名”列。在版本2中，您决定将其拆分为名字和姓氏，并删除“全名”列。通常，您可以编写脚本来添加新列，转换数据，然后删除旧列。但是，基于状态不会以这种方式工作，它只会删除列并添加新列，但不会做任何事情来转换数据。

基于迁移：这几乎是我们目前正在做的事情，除了一个非常大的文件而不是几个小文件。您从一个基线（可能是一个空数据库）开始，然后编写一个或多个文件，然后更改该基线以使其达到当前版本。例如，Version1.sql可能使用Full Name列创建Contacts表，然后Version2.sql可以创建First Name / Last Name列，移动数据，然后删除旧列。你可以使用只按正确的顺序运行每个脚本一次的工具，也可以做我们一直在做的事情，并拥有一个包含逻辑的大脚本，以了解已运行的内容和哪些内容。并且只做需要做的事。

优点和缺点：这基本上与国家相反。它为您提供了很多关于如何创建脚本的灵活性，以及使用真实逻辑以其需要的方式更新数据库的能力，而不是让它自动创建drop / alter / insert /等。脚本本身。就像基于状态一样，只要你有合适的工具，它就很容易部署。但是，通常不容易跟踪对数据库对象的更改。如果我想查看特定表的更改的完整历史记录，谁做了它，以及何时，实际上并不是一种简单的方法，因为没有一个文件用源表示该数据库对象控制历史。此外，我还没有看到任何可以采用基于迁移的策略的工具，并编译它以向您显示所做的更改是否存在任何参考问题。

所以，我的问题是：如何保持我们当前使用的基于迁移的功能，灵活性和易用性，同时也获得基于状态的最佳部分（版本控制和编译以检查依赖性））？我想要一些混合解决方案，只要它并不意味着我的开发人员必须管理两件事（比如写一个迁移脚本，但也不要忘记更新SQL项目，所以我们可以跟踪历史）。如果我可以自动化SQL项目来根据很酷的迁移来更新数据库对象脚本，但是需要知道是谁做出了导致更新的更改，最好是发生了什么变更。

思想？

在源代码管理中管理SQL文件

2 个答案: