任何使用“数据库项目”的人都可以 在视觉工作室中？
我最近尝试过（SQL 2008 版本），我发现它们相当不错。 好吧，唯一的问题是向导不够智能，无法在不首先删除所有数据的情况下更新数据库结构。 这就是这些项目没有在实践中使用的原因吗？
实际上从未见过有人使用它们或根本没有提到过它们。 除非您明确查找，否则在博客和论坛中也看不到任何内容。
他们怎么了？
I've recently given it a try (SQL 2008 version) and I find them quite okay. Well, the only problem is that the wizard is not intelligent enough to update database structure without first erasing all data. Is this why these projects are not used in practice?
Actually never seen anyone using them or ever mentioning them at all. Also nothing to be seen in blogs and forums unless you explicitly look for it.
What's wrong with them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我已经在一些付费项目中使用过它们，我认为它是一个很棒的工具。 也就是说，我看到了一些问题。
如果数据库项目文件夹中的 .dat 文件与数据库的临时实例不同步，架构比较将给出不准确的结果。 不确定这是如何发生的，请仔细检查模式比较，如果情况看起来有问题，请清除您的 .dat 文件（在关闭解决方案后）。
如果您有 20 多个数据库，并且它们相互引用并使用循环引用......这会造成伤害。 我还没有弄清楚如何让它适应这种情况。 GDR 2 似乎提供了一些希望。
I've used them on a few paid projects and I think its a great tool. Thats said, I've seen some issues.
If the .dat file in your db project folder gets out of sync with the temporary instance of the database, schema compare will give inaccurate results. Not sure how this happens, review schema compares carefully and blow away your .dat file (after closing solution) if things seem wrong.
If you have 20+ databases and they reference each other and use circular references... Its going to hurt. I haven't figured out how to make it scale to that scenario. GDR 2 seems to offer some promise.
我使用属于 Visual Studio 数据库版本一部分的数据库项目。 这是一个很棒的工具。 基本上，您在创建脚本中定义整个架构，然后将其签入源代码管理。 然后，它内置了工具来生成不同的脚本，顺便说一下，这些脚本不会删除数据。
它还具有数据比较工具，因此您可以比较数据库之间的数据并生成脚本以使数据库相同。
最近的 GDR 版本添加了一些有趣的功能。 这样听起来，如果您使用他们内置的部署方法，您可以生成一个部署包，当您运行它时，它将分析目标数据库并仅应用差异。
如果您有 Team Studio - Team Suite 或开发版本，则可以使用数据库版本。
尝试一下，这是数据库开发的巨大进步
I use the database project that is part of Visual Studio Database Edition. This is a great tool. Basically you define the entire schema, in create scripts which are then checked into source control. It then has tools built in to generate difference scripts, which by the way do not delete the data.
It also has data compare tools so you can compare data between database and generates the script to make the databases the same.
The recent GDR release has some interesting features added to it. Such that it sounds like if you use their built in deployment method you can generate a deployment package which when you run it will analyze the target database and apply only the differences.
If you have Team Studio - Team Suite or Development edition then you can use the Database Edition.
Give it a try and is a great evolution in database development
与 Glennular 一样，我们使用它们来版本控制我们的模式和 s'procs。
尽管我们有相当先进的版本控制结构（CI、自动部署到开发、单击部署到阶段和生产）； 我们在该结构中不包含任何数据库项目。 我们只是还不相信它。
更新：（对于 Out In Space）
我们针对公司的职能领域（销售、营销等）有单独的 TFS 项目。 在每个 TFS 项目中，我们都有一个 Main 和 Production 文件夹。 我们还有一个包含数据库项目的 TFS 项目和另一个包含通用程序集/视觉工作室项目的 TFS 项目。
发布后，我们从主分支分支到生产分支。 我们没有临时分支，因为我们行动太快，无法处理这个问题。 无论对错，我们的生产力部分取决于我们每周发布的生产级别版本的数量； 错误修复、新功能等。CI
在主分支上设置，以便每次签入都会导致构建服务器部署到我们的 DEV 环境。 然后运行单元和 Web 测试，如果成功完成，构建质量将自动设置为“开发”。 当有人将构建质量更改为“暂存中”时，这会导致任何先前的“暂存中”构建被设置为“拒绝”，并导致该构建被推送到我们的暂存服务器，同时更新配置文件以指向正确的服务器。 （我为此使用了 TFS Deployer 和 PowerShell 脚本）。
QA 在我们的临时服务器上进行测试。 一旦他们满意，生产团队就会将构建质量更改为“生产”。 这会导致构建被发送到生产区域，然后手动将其复制到正确的位置。 完成后，生产会通知开发人员，然后开发人员将该版本分支到 Production 文件夹中。 QA 还会收到通知，然后由他们进行一系列生产测试，以验证一切确实按预期工作。
我们设置了报告来向我们展示生产版本之间存在哪些变化，以便我们了解正在部署的每个检查。 这可以防止出现未知的情况，例如数据库更改等或其他一些潜在的破坏代码。
此外，我们的 BA 正在通过 Team System Web Access 跟踪工作项目，并了解这些项目何时投入生产。
尽管我们的 DBA 使用的是数据库版本 (GDR)，但他们对自动部署的控制级别并没有留下深刻的印象。 我希望Rosario为产品线带来一些更好的部署控制； 但在那之前我们还有 TFS Deployer 和 powershell。
Like Glennular, we are using them to version control our schema and s'procs.
Although we have a fairly advanced version control structure (CI, auto deployments to dev, single click deployments to stage and prod); we don't include any of the DB projects in that structure. We just don't trust it yet.
UPDATE: (for Out In Space)
We have separate TFS projects for functional areas of the company (Sales, Marketing, etc). Within each TFS project we have a Main and Production folder. We also have one TFS project which contains the Database projects and another one that contains Common assemblies / visual studio projects.
Upon release, we branch from Main to Production. We don't have a staging branch as we move too fast to deal with that. Right or wrong, our productivity is measured in part by the number of production level releases we do per week; bug fixes, new features, etc.
CI is set up on the Main branch such that every check in causes the Build server to deploy to our DEV environments. Unit and Web tests are then run and the build quality is automatically set to "Development" if it completes successfully. When someone changes the Build Quality to "In Staging" This causes any previous "In Staging" builds to be set to "Rejected" and causes that build to be pushed to our staging servers while updating the config files to point to the correct servers. (I used TFS Deployer and PowerShell scripts for this).
QA does testing out of our staging servers. Once they are happy, the production team changes the Build Quality to "Production". This causes the build to be sent to a Production area which then is manually copied to the correct location. Once completed, production notifies development who then branches that version into the Production folder. QA is also notified who then does a battery of Production tests to verify everything is indeed working as expected.
We have reports set up to show us what changes exist between production releases so that we know every check in that is being deployed. That prevents unknowns from popping up such as a database change etc. or some other potentially breaking code.
Further, our BA's are tracking work items via Team System Web Access and know when those items are in production.
Although our DBA's are using Database Edition (GDR), they haven't been impressed with the level of control for auto deployments. I'm hoping that Rosario brings some better deployment control to the product line; but until then we have TFS Deployer and powershell.
我们使用它们。 我们保留所有架构创建/更新脚本和存储过程。 主要目的是我们可以将项目连接到 SourceSafe 或 SVN。
这是控制 SQL 脚本版本的简单方法。
尝试在 VS 中进行一些 SQL 测试有点奇怪，但您可以找到解决方法。
更新
我们实际上已将其内置到我们的部署脚本中，我们的部署工具，遍历数据库项目（标记的文件夹除外）并运行所有脚本。 我们刚刚构建了一个用于运行该项目的快速工具。 如果有人有其他解决方案来部署数据库项目，那将会很有帮助。
We use them. We keep all of our schema creates/update scripts and Stored Procedures. The main purpose is that we can connect the project to a SourceSafe or SVN.
Its an easy way to keep your SQL scripts version controlled.
It is a little quirky trying to do some SQL testing in VS, but you find ways around it.
Update
We actually have it built into our deployment scripts, our deploy tool, goes through the DB project (except for flagged folders) and runs all the script. We just built a quick tool for run the project. If anyone has other solutions to deploy out the DB project that would be helpful.
我们使用数据库项目为 SQL 脚本提供版本控制。 我们也喜欢使用Visual Studio环境来编辑SQL； 对于我们的一些新开发人员来说，它比查询分析器更容易使用。
We use the database project to provide version control for our SQL scripts. We also like using the Visual Studio environment to edit the SQL; it's a little bit easier to use for some of our newer developers than query analyzer.