如何实际使用 Visual Studio Team System 数据库项目来版本化 Sql Server
如何正确使用 Visual Studio Team System 数据库项目对 sql server 数据库实现版本控制？
这可能看起来过于通用，但到目前为止我在网上找到的所有内容都没有帮助我实现任何有用的目标。我设法找到了与 Redgate 工具 Sql Compare 中的功能相似的功能，但它看起来绝对不像他们的产品那么直观。
根据我对这些数据库项目应该如何工作的理解，您可以拥有一个驻留在 Team Foundation Server 中（或位于 sql server 本身内部）的数据库版本，您可以将其签出到本地计算机工作中然后检查新的更改，这将允许同步开发像编码一样正常工作。难道我被误导了？或者只是一个复杂的设置过程？
相关的是如何使用它来将更改部署到临时/生产服务器？
How are you supposed to correctly use a Visual Studio Team System database project to implement version control on a sql server database?
This might seem overly generic but everything I've found so far online hasn't helped me in being able to achieve anything useful. I have managed to find functionality that appears to be similar to features that are in Redgate's tool Sql Compare but it definitely didn't seem as intuitive as their product.
From my understanding of how these db projects are supposed to work is that you're able to have a version of the database that either lives in Team Foundation Server (or inside the sql server itself) that you can check out to your local machine work on it and then check in the new changes which would allow for simultaneous development to work normally as it does for coding. Was I misinformed? Or is it just a complicated process to get setup?
Related is then how do you use it to deploy changes to the staging/production servers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们不使用它，我们只是简单地编写所有内容的脚本并将其像任何其他文件一样放入源代码管理中，并且所有对产品的部署都只能通过从源代码管理中拉取的脚本来实现。我认为真正的关键是，除了通过源代码控制脚本之外，没有任何东西可以放在产品上。一旦开发人员无法以任何其他方式将其更改进行生产（开发人员不应该拥有生产权利），就没有动力不将更改放入源代码管理中。
We don't use that, we simply script every thing and put it in source control like any other file and ALL deployments to prod are only through scripts pulled down from source control. I think the real key is that nothing gets put on prod except thorugh a source controlled script. Once the developer can't get his change to prod any other way (Devs should not have prod rights), there is no incentive to not put the change in source control.
有趣的是你应该问。我负责将我们的生产数据库置于版本控制之下，我们使用 Visual Studio Database Edition 来完成此任务。这是一个很棒的工具。这个工具的一个非常好的事情是，它不仅可以将您的模式置于版本控制之下，而且还可以验证您的数据库模式并允许您对其运行代码分析。它还允许重构操作和许多其他操作。
通常，我们针对本地开发数据库进行工作，将更改同步回 VSDE，构建数据库以确保没有警告或错误，然后创建部署脚本以部署到我们的生产数据库。
这是对我们执行此操作的内容和方式的简化说明，但我认为它可以让您大致了解如何使用它。我很乐意回答您的任何更具体的问题。
Funny you should ask. I am the one responsible for getting our production databases under version control, and we're using Visual Studio Database Edition to do it. It is a fantastic tool. The very nice thing about this tool is that not only will it keep your schema under version control but it will validate your database schema as well and permit you to run code analysis against it. It also allows refactoring operations, and many other things.
Typically we work against a local development database, synch the changes back to VSDE, build the database to make sure there are no warnings or errors, and then create a deployment script for deployment to our production databases.
This is a simplified explanation of what and how we doing this, but I think it gives you a general idea of how it can be used. I'd be glad to answer any more specific questions you have.