DROP VIEW xy CASCADE可能导致哪些潜在的非明显数据丢失？
我正在使用数据库迁移，并且作为一个功能；可重复迁移"-包含SQL的文件，每次至少应用一次新的迁移后都会重新运行这些文件。在我的情况下，它们通常包含以下内容：
DROP VIEW IF EXISTS x_y;
CREATE VIEW x_y AS ...
(我使用这种方法来定义常见视图，因为否则我通常必须在旧的迁移中找到视图的最新版本，然后几乎逐字逐句地重复它，只增加一两列，这很快就会变得非常冗长和容易出错(
最近，我遇到了越来越多的依赖性问题，我必须手动删除将在以后的可重复迁移中创建的视图(否则会出现Cannot drop view XY because other objects depend on it错误(。我不想使用ALTER VIEW，因为它不允许我删除或重新排序列，所以简单地使用DROP VIEW xy IF EXISTS CASCADE变得很诱人，但我担心隐藏的数据丢失。思考可能被丢弃的东西：
其他视图：如果删除其他视图，也不会太糟糕，因为应用程序集成测试&代码生成会捕捉到这一点(我的数据库对象被生成为类型安全的代码，因此一旦在应用程序代码中的任何地方使用了丢失的视图，它就不会通过编译器(。
触发器：这可能很糟糕，因为在可重复迁移中未生成的触发器可能会被删除而不会重新创建，从而导致信息丢失，尽管如果集成测试涵盖了触发器，这是可以管理的
还有别的吗？表数据会丢失吗(再说一遍，应用程序代码和单元测试可能会在接近生产之前发现这一点(？有没有一种方法可以让数据在迁移过程中被擦除，而不会在单元中被注意到；集成测试(因为这些测试通常测试功能，但不是预先存在的数据(？
还有别的吗？
我脑子里没有其他东西，但如果是其他东西，你会看到DROP cde的错误。
是否可以表数据？
这是主要问题，第一个答案应该是否定的。
也就是说，你可能会有糟糕的数据设置，例如，一个由触发器更新的计算字段，并且你可能会忘记在更改视图后重新创建它。。。你可能不会立即看到这一点，但正常情况下应该能够在之后纠正。