管理“非 SQL Server”的最佳方法是什么？ Visual Studio 2010 中的 SQL 对象？

发布于 2024-12-05 11:00:21 字数 403 浏览 1 评论 0原文

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

有人在使用“非 SQL Server”数据库的数据库项目方面取得过成功吗？我们使用 Sybase - 它使用 T-SQL 并且与 SQL Server 非常相似，所以我对此充满希望。

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

任何想法都会受到欢迎。

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

宛菡 2024-12-12 11:00:21

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

我将所有 SQL 对象添加到 Visual Studio .dbproj 项目中它们自己的 .sql 文件中。但是，Sybase 版本的 RAISERROR 和 Microsoft 版本的 RAISERROR 导致 Visual Studio 中内置的验证代码变得不满意。数据库项目的问题在于，这实际上导致了编译错误——这基本上使它成为一个阻碍。

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

为了获得 .dbproj 的一些好处，我考虑编写一个完整的 SQL 解析器，但很快就被 SO 上的一些帖子劝阻了。相反，我使用正则表达式进行了一些基本解析 - 这让我无需付出太多努力就获得了一些很酷的功能：

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

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

OK, I'll answer my own question.

I added all of our SQL objects to their own .sql files within a Visual Studio .dbproj project. However, minor syntactic incompatibilities between the Sybase version of RAISERROR and the Microsoft version of RAISERROR caused the validation code built into Visual Studio to get unhappy. The problem with the database project was that this actually caused a compilation error - which basically made it into a show-stopper.

So I scrapped that idea and added the .sql files to a standard .csproj project file. I then implemented some custom code that would load all of the .sql files, and aggregate them into a deployment script when invoked. I added a call to the custom code to the post build of the .csproj file so that whenever it was compiled - it would output a deployment script - which works like a dream with our build server.

In order to get some of the benefits of the .dbproj, I looked into writing a full SQL parser, but was quickly discouraged by some of the posts on SO. Instead I did some rudimmentary parsing with regex - which got me a few cool features without a lot of effort:

The code could detect dependencies between the various .sql files, and add them to the deployment script in the correct order to avoid sysdepends warnings.
Where there were no dependencies, objects were ordered based on the object type (stored procedure, function, grant statement, etc) and then by name so that the resulting script was always ordered the same - which is very important if you need to diff two versions of the script.
The deployment script can figure out some of the required permissions, so I don't need to keep track of all of the GRANT statements.
Stored procedures that are in the database but not in the script can be dropped automatically - so I don't need to keep track of what state each database is in - we just run the script and everything is in the correct state.
We have a few stored procedures that our automated tests call that shouldn't be deployed. The code can detect these and include them in a Debug build and exclude them in a Release build.
The custom code also generates a diff script that determines what changes the deployment script will make to a database and prints them out. This allows the person who is running the script to get an idea of what it will do. For example, the diff script might tell them that no changes will be made - so they don't need to run the deployment script at all - which is kind of handy if it saves them logging in at 3am to take a database offline and take backups etc.

So the end result is that all of my SQL objects are in separate files making them easy to work with in Visual Studio and manage under source control. For the first time since I started this job, I can look at the history in source control and tell what files have been changed (before this we had one enormous .sql file with absolutely everything in it).

回复收藏 0 原文

~没有更多了~