了解 SQL 数据库项目工作流程

发布于 2025-01-08 12:16:29 字数 225 浏览 1 评论 0原文

我的 SQL 2008 数据库项目的构建过程 1 次构建需要 15 分钟以上。我只需要管理大约 50 个存储过程。我创建了一个数据库项目和一个服务器项目。

接下来我要做的就是修复所有构建错误。现在我修改一个存储过程。然后我必须构建整个数据库并编写整个数据库的脚本来查看我的存储过程是否可以编译。

有没有办法测试存储过程而不需要经过 15 分钟的构建 - 然后部署脚本?我可以只构建更改而不是整个数据库吗?

The build process for my SQL 2008 Database Project takes upwards of 15 minutes for 1 build. I only need to manage roughly 50 stored procedures. I created a database project and a server project.

Next thing I do is fix all the build errors. Now I modify a stored procedure. Then I have to build the entire database and script the entire database just to see if my stored procedure compiles.

Is there any way to test the stored procedure without going through a 15 minute build - then deploy the script? Can I build just changes instead of the entire DB?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

半边脸i 2025-01-15 12:16:29

首先,您应该看看为什么您的构建需要这么长时间。也许您需要更多内存或其他东西。

其次,为什么必须编写整个数据库的脚本来测试存储过程?只需部署到测试数据库,甚至本地沙箱数据库即可。

First of all, you should look at why your builds take so long. Maybe you need more memory or something.

Second, why do you have to script the entire database to test the stored procedure? Just deploy to a test database, or even your local sandbox database.

追星践月 2025-01-15 12:16:29

我决定选择 MSSCCI。它是一个简单的 UI,可以直接插入 SSMS,并且表现得像团队资源管理器,这正是我一直在寻找的。 开始使用。< /a>

I decided to go with MSSCCI. It's simple UI which plugs directly into SSMS and behaves like Team Explorer is exactly what I've been searching for. Getting started.

森罗 2025-01-15 12:16:29

我从未使用视觉工作室来“构建”和维护数据库。我猜想,随着数据库开始变大,这很快就会变得难以管理。我假设当您“构建”它时,它正在验证和部署数据库中的所有对象。

我建议您不要以这种方式使用视觉工作室。只需独立维护你的sql代码即可。并将它们手动存储在版本控制系统中。这样您就可以单独更新每个存储过程。换句话说,将每个存储过程保存为一个文件。

if object_id(<ProcName>) is not null
    drop proc <ProcName>
GO

create proc <ProcName>
...
GO

然后,将其存储为 ProcName.sql 并让源代码管理处理其余部分。抱歉,如果这没有帮助或者我只是陈述显而易见的事情。

I've never used visual studios to "build" and maintain databases. This, I'd guess, will quickly become unmanageable as the database starts getting bigger. And I'm assuming when you "build" it, it's verifying and deploying all objects in the database.

I would suggest you do not use visual studios in this fashion. Just maintain your sql code independently. And store them in version control systems manually. That way you can update each stored procs separately. In other words, keep each stored proc as a file.

if object_id(<ProcName>) is not null
    drop proc <ProcName>
GO

create proc <ProcName>
...
GO

Then, store that as ProcName.sql and let source control handle the rest. Sorry if this isn't helpful or if I'm just stating the obvious.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文