使用Flyway之类的数据库迁移工具播种数据是一种良好的做法吗？
我们正在为我们的项目设置Flyway，我们正在重新考虑是否要使用Flyway迁移或手动使用sql控制台或某些引导脚本来播种数据。
我们担心的是，如果我们在Flyway中添加种子数据，这意味着还需要在Flyway中进一步修改这些数据。而且我们可能需要使用field=x或其他一些在某个时间点可能已经无效的条件，因为应用程序可以更改数据。这将是个问题。
在他们的文档中，我看不到任何建议不使用种子数据的内容。
我只是想知道使用Flyway这样的迁移工具来播种数据是否是个好主意。
共有1个答案
最佳拟合通常是参考数据，答案是明确的“是”。对于用户可修改的数据，这取决于。如果所有环境最初都需要这些数据，那么答案可能也是肯定的。最后，如果where条件在以后的特定环境中不再成立，这可能也意味着您无论如何都不想覆盖该数据。或者，您需要为所有行分配固定的合成ID和不可变ID，这样您以后就可以随时引用这些ID，即使在数据更改的情况下也是如此。
-
数据库迁移工具 首先通过 composer 安装 composer require topthink/think-migration 注意事项，不支持修改文件配置目录 在命令行下运行查看帮助，可以看到新增的命令 php think migrate migrate:create Create a new migration migrate:rollback Rollback t
-
我正在尝试使用flyway，但是我有一个不知道如何解决的情况: 当我应用STANDARD脚本时，我必须运行V1.0__create_table_TAB1.sql当我将脚本应用到customer1时，TAB1表是一个视图，因此我必须运行V1.0__creaate_view_TAB1_to_schema1.sql。 实际： 应始终应用sql_common文件夹的脚本，但不应应用 V1.0（创建表 TA
-
我的团队目前有几个试用版客户在使用我们的产品。当前将客户的数据库升级到最新版本的方法包括重新初始化数据库和手工重新创建客户配置，这并不多，但肯定很繁琐，并且会随着我们实施某种迁移策略而改变。 我的问题是，是否可以使用flyway（或其他一些工具）来管理我们产品的所有实例的数据库模式迁移，同时保留独立的实例数据？解决这类问题的最佳方法是什么。
-
我正在尝试配置Spring Boot和Flyway,以便使用Spring Boot 2.2.6和Flyway 5.2.3对两个不同的数据源应用单独的迁移。 主要数据源： 第二个数据源： 数据源连接属性： Flyway迁移： 目录结构： 迁移脚本仅正确应用于数据库。 问题是，和中的脚本被应用到数据库，而只应用主目录中的脚本。 如何配置Flyway以仅将目录中的迁移脚本应用于数据库？
-
在Android上，有两种可能的方式通过广播接收器收听系统事件： 静态地，通过清单 由于一些项目包含大量活动、服务和“管理器”类，因此使用一个BroadcastReceiver通知应用程序上的所有侦听器所发生的事情，而不是使用多个BroadcastReceiver（以及它们的代码处理），可能会很有用。 这种广播接收器的一个示例是侦听连接更改的接收器： 目的是在应用程序处于活动状态时（通过服务和/或
-
当尝试使用artisan迁移数据库中带有表“user”的Laravel 4时： 我收到此错误： C： \xampp\htdocs\laravel [21.04.2014 02:27:56通知]目前不允许事件报告。Reaso ns：启动前或关闭后{"错误"：{"类型"："Symfony\Component\HttpKernel\Exception\NotFoundHttpExcepti on"，"消