在源代码管理中管理我的数据库 [英] Managing My Database in Source Control
问题描述
由于我正在使用一个新的数据库项目（在VS2008内），并且我从来没有从头开发数据库，我立即开始研究如何在源代码控制（在这种情况下，Subversion）管理数据库。 / p>
我发现了一些关于SO的信息，包括这篇文章：在多个环境中保持开发数据库同步。 特别是其中的一个答案指向
我正在阅读 K. Scott Allen的一系列帖子，描述了他如何管理数据库更改。从我的阅读（请请原谅我的问题的noobishness），似乎好像数据库本身从来没有检查到存储库。相反，可以构建数据库的脚本以及测试数据（也是从脚本填充的）被检入到存储库中。最终，这意味着，当开发人员测试他或她的应用程序时，这些脚本是构建过程的一部分。这确保数据库是最新的，但也是从每个开发人员的机器本地运行。
这对我有意义（如果我确实正确地读取）。但是，如果我错过了一些东西，我会感谢校正或额外的指导。此外，另一个我想问的问题 - 这也意味着我应该不签入创建的 mdf 或 ldf 文件Visual Studio？
感谢您的帮助和其他见解。总是很感激。
这是正确的，你应该检查脚本而不是数据库文件本身。
我不喜欢从测试数据构建，除非数据本身将模仿生产的数据大小（或在新数据库的情况下）。为什么？因为针对具有100条记录的表写入代码并不能告诉你，当你有10,000,000条记录时，它是否会及时运行。我有太多的坏设计选择，从人认为一个小数据集是可以开发。
在这里，我们不允许开发人员在其框上有一个单独的数据库（这通常限制数据库的大小，而不是连接到SAN的服务器），而是他们必须对dev数据库工作，这是从prod（然后所有新的dev脚本运行）定期刷新，以保持数据正确的大小。我认为重要的是，你的dev数据库环境匹配prod尽可能接近，包括设备配置，数据库的大小等。没有什么比花费很长时间开发一些东西，根本不工作在prod或必须立即取下，因为它减慢了系统太多。
现在跳下我的肥皂盒。
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.
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屋！
