生产数据库上的数据迁移

发布于 2024-11-02 18:24:27 字数 260 浏览 1 评论 0原文

有没有什么方法可以在生产数据库上进行数据迁移而不使用SQL?

我们正在使用 MigratorDotNet,当我们为应用程序构建一个新功能来更改数据库方案时,我们需要进行一些数据更新,我们必须执行这些复杂且麻烦的 SQL 语句,以便数据在生产中保持一致。

想知道是否还有其他方法可以做到这一点,最好的做法是什么?关于其他可能的解决方案有什么想法吗?

我们不能使用像 NHibernate 这样的东西,因为这样当方案改变时我们必须不断修复旧的迁移,这很容易出错。

Is there any way to have data migrations on production database not to be with SQL?

We are using MigratorDotNet and when we build a new funcionality for the application that changes the scheme of the database and we need to do some data updates we have to do this complex and troublesome SQL statements so the data is consistent on production.

Was wondering if there was another way to do this, what are the bests practices to do this? Any ideas on other possible solutions?

We cannot use something like NHibernate because then we have to keep fixing old migrations when the scheme changes, and that can be error prone.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

笨死的猪 2024-11-09 18:24:27

诀窍是使用迁移工具并将所述数据操作语句折叠到迁移中。我们通常在几个项目中使用同一事物的扩展版本,它绝对可以处理这个技巧。

The trick is to use your migration tool and fold said data manipulation statements into the migrations. We use an extended version of the same thing typically for a few projects and it can definitely handle that trick.

荒岛晴空 2024-11-09 18:24:27

如果您已经在使用 Migrator.NET 这样的迁移工具,那么我想说您已经成功了。复杂的模式/数据更改只是 RDBMS 世界中的一个事实。

If you're already using a migration tool like Migrator.NET then I'd say you're most of the way there. Complex schema/data changes are just a fact of life in the RDBMS world.

天生の放荡 2024-11-09 18:24:27

试试螨虫。它可以让你做任何你可以用 sql 做的事情,并使用 sql 来完成它,但能够确保你的数据库处于所需的版本,并且不会冒险执行已经运行的脚本(或错过脚本),从而离开你的数据库处于一致状态。

如果你的开发者采用这个。部署是一个简单的小更新,然后您就知道问题与产品相关或与数据相关(但与架构无关)。

https://github.com/soitgoes/mite

让我知道你的想法。我开发了这个,并与我的团队一起使用它多年,取得了巨大的成功。

Try mite. It let's you do anything that you can do with sql and use sql to do it but have the ability to ensure your database is on the desired version and not risk executing a script that has already run (or miss a script), leaving your database in a consistent state.

If your developers adopt this. Deployments are a simple mite update and then you know problems are product related or data related (but not schema related).

https://github.com/soitgoes/mite

Let me know what you think. I developed this and have been using this with my team for years with great success.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文