在 Visual Studio 2010 中管理“非 SQL Server”SQL 对象的最佳方式是啥？

Posted 2023-03-23

【中文标题】在 Visual Studio 2010 中管理“非 SQL Server”SQL 对象的最佳方式是啥？

【英文标题】：What is the best way to manage "non-SQL Server" SQL objects within Visual Studio 2010?在 Visual Studio 2010 中管理“非 SQL Server”SQL 对象的最佳方式是什么？

【发布时间】：2011-09-19 13:40:58

【问题描述】：

Visual Studio 有一个用于 Sql Server 的数据库项目。这有许多优点：它将配置设置和数据库对象托管在一个地方。 .sql 文件是常规 .NET 解决方案的一部分 - 在解决方案资源管理器中可见，在 Visual Studio 中可编辑。他们有一个生成部署脚本的机制。将每个单独的数据库对象放在自己的文件中，大大简化了更改跟踪和源代码控制。

有没有人成功地将数据库项目与“非 SQL Server”数据库一起使用？我们使用 Sybase - 它使用 T-SQL 并且与 SQL Server 非常相似，所以我充满希望。

或者有其他方法吗？我想我可以使用标准项目 (.csproj) 并调用自定义命令行应用程序作为后期构建的一部分，以将 .sql 文件转换为部署脚本。

欢迎提出任何想法。

谢谢

【问题讨论】：

如果你创建 N 个存储的 Sybase 存储过程，那些可以是版本控制的，对吧？ TFS 不关心目标数据库是什么——它是一个文本文件，因此它可以在源代码控制下。要求澄清，因为标题与正文不太同步（VSTS DB 项目可以与 Sybase 一起使用）

@billinkc - 是的，最简单的部分是创建 N 个 .sql 文件并将它们纳入源代码控制。只是他们很难像那样工作。我希望它们成为我在 Visual Studio 中的常规 .NET 解决方案的一部分。只是想知道是否有更好的方法。数据库项目看起来很棒，但似乎完全面向 Microsoft Sql Server。一定有人在使用 Visual Studio 和 TFS 的其他数据库。标题原本是“What's the best way...”，但题主说太主观了:-(

我认为这与 TFS 无关，我会重写问题以专注于如何塑造 VS 解决方案以包含 Sybase 对象。如果你实现了它，只需检查它！

好的，我已经根据您的反馈@pantelif 重写了问题。对不起，如果这让你的 cmets 看起来有点格格不入。我想源代码控制对我来说是一个重要方面，但我使用 TFS 的事实无关紧要。

您是要从已构建的 Sybase 数据库创建数据库项目并将架构逆向工程到文件中，还是已创建文件？我不确定它是否会对非 SQL Server 进行逆向工程，但也许有一个模板，就像 Oracle 的模板一样。至于将文件添加到您的解决方案中，您应该能够使用 SQL Server 文件夹结构添加它们，在您需要的地方更改它。如果您只是在寻找源代码控制，您可以随时使用 Windows Explorer 的 TFS 插件。

【参考方案1】：

好的，我会回答我自己的问题。

我将所有 SQL 对象添加到 Visual Studio .dbproj 项目中它们自己的 .sql 文件中。但是，Sybase version of RAISERROR 和 Microsoft version of RAISERROR 之间的少量语法不兼容导致 Visual Studio 中内置的验证代码不满意。数据库项目的问题在于，这实际上导致了编译错误 - 这基本上使它成为了一个显示停止器。

所以我放弃了这个想法并将 .sql 文件添加到标准 .csproj 项目文件中。然后我实现了一些自定义代码，这些代码将加载所有 .sql 文件，并在调用时将它们聚合到部署脚本中。我在 .csproj 文件的后期构建中添加了对自定义代码的调用，这样无论何时编译它 - 它都会输出一个部署脚本 - 这对我们的构建服务器来说就像一个梦想。

为了获得 .dbproj 的一些好处，我打算编写一个完整的 SQL 解析器，但很快就被 SO 上的一些帖子劝阻了。相反，我使用正则表达式进行了一些基本的解析——这让我不费吹灰之力就获得了一些很酷的功能：

该代码可以检测各种 .sql 文件之间的依赖关系，并以正确的顺序将它们添加到部署脚本中以避免 sysdepends 警告。 在没有依赖关系的情况下，对象是根据对象类型（存储过程、函数、授权语句等）然后按名称排序的，这样生成的脚本总是按相同的顺序排序 - 如果您需要，这非常重要来区分脚本的两个版本。 部署脚本可以找出一些必需的权限，因此我不需要跟踪所有的 GRANT 语句。 可以自动删除在数据库中但不在脚本中的存储过程 - 所以我不需要跟踪每个数据库的状态 - 我们只需运行脚本，一切都处于正确状态。 我们的自动化测试调用了一些不应部署的存储过程。代码可以检测到这些并将它们包含在 Debug 构建中并在 Release 构建中排除它们。 自定义代码还会生成一个差异脚本，该脚本确定部署脚本将对数据库进行哪些更改并将其打印出来。这允许运行脚本的人了解它将做什么。例如，diff 脚本可能会告诉他们不会进行任何更改 - 所以他们根本不需要运行部署脚本 - 如果它保存他们在凌晨 3 点登录以使数据库脱机并采取备份等。

所以最终结果是我的所有 SQL 对象都位于单独的文件中，这使得它们易于在 Visual Studio 中使用并在源代码控制下进行管理。自从我开始这项工作以来，我第一次可以查看源代码控制中的历史记录并了解哪些文件已被更改（在此之前，我们有一个巨大的 .sql 文件，其中包含所有内容）。

【讨论】：

我遇到了完全相同的问题，我想知道您是否可以分享您的解决方案代码以及如何使用它。谢谢

@AlexanderGaisman - 不幸的是，代码属于我的雇主，所以我不能分享。上面的基本思想（控制台应用程序从每个对象的单独 .sql 文件生成 .sql 部署脚本）效果很好，不需要太多编码。最难的部分可能是依赖跟踪。自从我发布此内容以来，我们已经采取了更进一步的措施，因此生成的脚本还包括以下能力： 无需停机即可部署存储过程（摆脱上面的 6 个）；检测更改并仅应用增量（摆脱 4）；根据检测到的架构等应用不同的存储过程版本。