以前的答案似乎都没有提到的另一种用法是更易于部署表结构更改。

假设您希望停用T_OLD包含活动用户数据的表（），而改用具有相似数据（名为T_NEW）的新表，但该表同时包含活动用户和非活动用户的数据，并增加一列active。

如果您的系统中有大量的查询，则SELECT whatever FROM T_OLD WHERE whatever可以采用两种选择：

1） Cold Turkey- 更改数据库，同时更改，测试和发布包含所述查询的大量代码。很难做到（甚至协调），非常冒险。坏的。

2） 渐进式 -通过创建T_NEW表，删除T_OLD表并创建一个名为 VIEW的VIEW 来更改数据库，该
VIEWT_OLD模仿T_OLD表100％（例如，视图查询为SELECT all_fields_except_active FROM T_NEW WHERE active=1）。

这样一来，您就可以避免释放当前从中选择的任何代码T_OLD，并进行更改以将代码从轻松地迁移T_OLD到T_NEW。

这是一个简单的示例，还有很多其他方面。

PS另一方面，您可能应该有一个 存储过程API， 而不是来自的直接查询T_OLD，但这并非总是如此。