您如何处理多个开发人员和数据库更改？
我想知道你们如何处理 2 个或更多开发人员小组中的开发数据库更改？您是否拥有每个人都可以访问的全局数据库，也许是本地副本并手动应用脚本更改？很高兴看到您注意到的每种方法的优缺点以及团队中的开发人员数量。
I would like to know how you guys deal with development database changes in groups of 2 or more devs? Do you have a global db everyone access, maybe a local copy and manually apply script changes? It would be nice to see pros and cons that you've noticed for each approach and the number of devs in your team.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
从 Martin Fowler 的“进化数据库设计”开始。这很好地总结了
还有其他关于数据库开发的问题也可能有用，例如 RedGate SQL 源代码管理适合我吗？
Start with "Evolutionary Database Design" by Martin Fowler. This sums it up nicely
There are have been other questions about DB development that may be useful too, for example Is RedGate SQL Source Control for me?
我们的方法是每个人都有自己的数据库，如果需要，可以通过使用基础数据创建脚本来创建完整的数据库。为此所需的所有脚本都在源代码管理中。
所有脚本都是
CREATE脚本，它们反映了数据库模式的当前状态。升级位于单独的 SQL 文件中，可以将现有数据库从特定版本升级到较新版本（按顺序运行）。应用所有更新后，架构必须与运行安装脚本所获得的架构相同。我们有一些工具可以做到这一点（我们使用 SQL Server 和 .NET）：
该工具集作为开源项目提供（在 LGPL 下许可） ），它称为 bsn ModuleStore（请注意，它仅限于 SQL Server 2005 /2008/Azure 以及运行时部分的 .NET）。
Our approach is that everyone has their own DB, the complete DB can be created from create scripts with base data if required. All the scripts required for this are in source control.
All scripts are
CREATEscripts and they reflect the current state of the database schema. Upgrades are in separate SQL files which can upgrade existing DBs from a specific version to a newer one (run sequentially). After all the updates have been applied, the schema must be identical to what you would get from running the setup scripts.We have some tools to do this (we use SQL Server and .NET):
The toolset is available as open-source project (licensed under LGPL), it's called the bsn ModuleStore (note that it is limited to SQL Server 2005/2008/Azure and to .NET for the runtime part).
我们使用代号为“Data Dude”的东西（TFS 和 Visual Studio 中的数据库功能）来处理这个问题。当您“获取最新”并引入依赖于架构更改的代码时，您还引入了修订后的架构、存储过程等。您右键单击数据库项目并部署；使您的本地架构和 sp 同步，但不会覆盖您的数据。编写脚本以将旧模式转换为新模式的工作由 Visual Studio 承担，而不是由您或您的 DBA 负责。我们还为省份列表等内容提供“填充”脚本，并为您部署运行它们。
比旧的方式好多了，旧的方式总是在高压力的时候崩溃，人们检查代码然后回家，没有人知道要添加哪些列才能使代码工作等。
We use what was code named "Data Dude" - the database features in TFS and Visual Studio - to deal with this. When you "get latest" and bring in code that relies on a schema change, you also bring in the revised schemas, stored procedures etc. You rigght-click the database project and Deploy; that gets your local schema and sp in sync but doesn't overwrite your data. The job of working out the script to get you from your old schema to the new one falls to Visual Studio, not to you or your DBA. We also have "populate" scripts for things like lists of provinces and a deploy runs them for you.
So much better than the old way which always fell apart at high stress times, with people checking in code then going home and nobody knowing what columns to add to make the code work etc.