在源代码管理中管理我的数据库
由于我正在处理一个新的数据库项目（在 VS2008 中），而且我从未从头开始开发数据库，因此我立即开始研究如何在源代码管理（在本例中为 Subversion）中管理数据库。
我找到了一些关于SO的信息，包括这篇文章：将开发数据库保留在多个环境同步。 其中一个答案特别指出许多链接，所有这些链接都有很好的、有用的信息。
我正在阅读 系列K. Scott Allen 的帖子描述了他如何管理数据库变更。从我的阅读来看（请原谅我的问题的愚蠢），似乎数据库本身从未被签入存储库。相反，可以构建数据库的脚本以及测试数据（也由脚本填充）被签入存储库。最终，这意味着，当开发人员测试他或她的应用程序时，将运行这些作为构建过程一部分的脚本。这确保了数据库是最新的，但也可以在每个开发人员的计算机上本地运行。
这对我来说很有意义（如果我确实正确地阅读了的话）。但是，如果我遗漏了什么，我将不胜感激纠正或额外指导。此外，我想问的另一个问题 - 这是否也意味着我不应该签入从创建的 mdf 或 ldf 文件视觉工作室？
感谢您的任何帮助和额外的见解。一直很赞赏。
As I am working with a new database project (within VS2008), and as I have never developed a database from scratch, I immediately began looking into how to manage a database within source control (in this case, Subversion).
I found some information on SO, including this post: Keeping development databases in multiple environments in sync. One of the answers in particular pointed to a number of a links, all of which had good, useful information.
I was reading a series of posts by K. Scott Allen which describe how he manages database change. From my reading (and please pardon the noobishness of my question), it seems as though the database itself is never checked into a repository. Rather, scripts that can build the database, along with test data (which is also populated from scripts) is checked into the repository. Ultimately, this means that, when a developer is testing his or her app, these scripts, which are part of the build process, are run. This ensures that the database is up-to-date, but is also run locally from every developer's machine.
This makes sense to me (if I am indeed reading that correctly). However, if I am missing something, I would appreciate correction or additional guidance. In addition, another question I wanted to ask - does this also mean that I should NOT check in the mdf or ldf files that are created from Visual Studio?
Thanks for any help and additional insight. Always appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这是正确的，您应该签入脚本而不是数据库文件本身。
我不喜欢根据测试数据进行构建，除非数据本身会模仿生产中拥有的数据大小（或者在新数据库的情况下，旨在拥有的数据大小）。为什么？因为针对具有 100 条记录的表编写代码并不能告诉您当您有 10,000,000 条记录时它是否会及时运行。我有太多糟糕的设计选择，这些选择是由那些认为小数据集适合开发的人做出的。
在这里，我们不允许开发人员在其设备上拥有单独的数据库（这通常会由于不是连接到 SAN 的服务器而限制数据库的大小），相反，他们必须针对定期刷新的开发数据库进行工作prod（然后运行所有新的开发脚本）以保持数据正确的大小。我认为你的开发数据库环境与产品尽可能匹配是很重要的，包括设备配置、数据库大小等。没有什么比花很长时间开发一些在产品上根本无法工作或必须在产品上工作的东西更令人沮丧的了。立即删除，因为它使系统速度减慢太多。
现在从我的肥皂盒上跳下来。
That is correct you should check in scripts not the database file itself.
I'm not a fan of building from test data unless the data itself will mimic the size of data that production has (or in,the case of new databases, is intended to have) . Why? because writing code against a table with 100 records doesn't tell you if it will run in a timely fashion when you have 10,000,000 records. I've way too many bad design choices made from people who think a small data set is OK for development.
Here, we do not allow devs to have a separate database on their box (which typically limits the size the database can be by virture of not being a server attached to SAN), instead they must work against the dev database which is periodically refreshed from prod (and then all the new dev scripts run) to keep the data the right size. I think it is important that your dev datbase environment match prod as closely as possible including equipment configuration, size of the database etc. Nothing more frustrating than spending a long time developng something that either won't work at all on prod or has to be taken down immediately because it is slowing the system too much.
Jumping down off my soapbox now.
签入脚本是个好主意，因为源代码控制最适合处理文本文件，而不是二进制文件。作为与数据库更改相关的其余代码更改的一部分，可以轻松查看脚本文件中的差异。除了签入数据库脚本之外，我们还签入数据库模式快照。此数据库模式快照允许我们验证生产中的模式是否与给定产品版本的预期模式匹配。除此之外，数据库架构快照是使用纯文本编辑器搜索列和表的便捷方法。
It is great idea to check in scripts, since source code control is best suited to working with text files, rather than binary files. Differences in the script files can be easily reviewed as part of the rest of your code changes related to the database change. In addition to checking in the database scripts, we also check in a database schema snapshot. This database schema snapshot allows us to verify that the schema in production matches the expected schema for given version of the product. Besides that, the database schema snapshot is a handy way for searching for columns and tables using a plain text editor.
我使用 DataConstructor 但有偏见，因为它是我写的。
I use DataConstructor but am biased because I wrote it.
尝试 SQL 检查器：
如何将数据库置于版本控制之下
Try SQL Examiner:
How to keep your database under version control
您可以使用 Liquibase 之类的工具来管理数据库脚本。它实际上是一个数据库升级框架，因此它将跟踪已经执行的步骤，因此，例如，当您想要升级生产时，它只执行新步骤。
You could use a tool like Liquibase to manage the database scripts. It is really a database upgrade framework, so it will keep track of the steps that have executed already, so when you want to upgrade production, for example, it only executes the new steps.