数据库升级方法
一般来说，数据库的模式会随着时间的推移而改变。在构建之间，可能会发生零到多次架构更改。捕捉这些变化的“最佳实践”是什么？
例如，假设 2 个开发人员正在开发一个项目并使用 git 进行源代码控制。他们同意在周五进行建造。每个人都开始工作，使用更新到当前架构的数据库迁移脚本检查更改。当 A 获得 B 的更改时，他们如何轻松知道要运行哪些升级脚本？当一个人查看服务器上的数据库时，他们如何知道自己使用的是哪个版本？如果数据库捕获了版本号，则意味着在周五，团队中的一个人必须对其其他所有人说“好吧，大家签到，然后我将编写一个脚本，将版本号更新为下一个版本号”。版本并签入。”
有没有标准的方法来解决这个问题？谢谢。
In general, the schema of a database will change over time. Between builds, zero to many schema changes can occur. What is a "best practice" for capturing these changes?
For example, let's say 2 developers are working on a project and using git for source control. They agree to have a build on Friday. Each go about their work, checking in changes with database migration scripts that update to the current schema. When person A gets person B's changes, how can they easily know which upgrade scripts to run? When a person is looking at a database on a server, how can they know which version they are on? If the database captures the version number, that means that on Friday, one of the people on the team had to say to everyone else "Ok, everyone check in, then I am going to write a script that updates the version number to the next version and check it in."
Is there a standard way to approach this? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
考虑为每个数据库[结构]更改编写一个迁移，而不是每个系统的稳定版本。就像代码的修订一样：每次更改都会更新系统并增加其修订版（而不是版本）。
通常我们将数据库修订版（以及“公共”版本）存储在一个特殊的表中。有时我们存储应用于此数据库的迁移脚本的名称，但这是更复杂的解决方案。在文件名中包含应用迁移后的数据库修订版本很方便。迁移脚本中的最后一行更新特殊表中的迁移版本。
要确定将哪些迁移应用于具体开发人员的数据库，您只需获取修订版号高于存储在特殊表中的数据库修订版的所有迁移。
Consider writing one migration per database [structure] change, not per stable version of your system. Just like revisions of code: every change updates system and increments it's revision (not version).
Usually we store database revision (along with 'public' version) in a special table. Sometimes we store names of migration scripts that were applied to this database, but it's more complex solution. It's handy to inlude revision of database which would be after applying migration in the file name. Last line in migration script updates migration version in a special table.
To determine which migrations to apply to concrete developer's database, you just take all the migrations that have higher revision number than revision of database that is stored in a special table.