sql - 可修改的连接 View 是合理的设计选择吗？

Question

明确地说，可修改的加入 View 是指由两个或多个表的连接构成的 View ，允许插入/更新/删除操作修改任何/所有的组件表。

这可能是一个特定于 postgres 的问题，不确定。如果其他 DBMS 具有可修改连接 View 的特殊功能，我也很感兴趣，因为据我所知，它们在标准 SQL 中是不可能的。

我正在研究 postgres 模式，我最近的一些阅读建议可以使用替代规则构建可修改的连接 View (CREATE RULE ... DO INSTEAD ... ).可修改的连接 View 似乎是可取的，因为它允许在接口(interface)后面隐藏强大的规范化，为经典抽象提供一种机制。规则是实现的唯一选择，因为目前 triggers cannot be set on views .

但是，我尝试设计的第一个可修改 View 遇到了问题，我发现许多人认为非平凡规则是有害的(请参阅 this SO answer 评论中的链接)。另外，我在网络上找不到任何可修改的连接 View 的示例。

问题(编辑以在问题上提出更精细的要点):

• 您对可修改的连接 View 有任何经验吗？您能提供一个具有选择/插入/删除/更新功能的具体示例吗？
• 它们是否实用，即是否可以透明地处理它们而不必小心翼翼地绕过地雷/黑洞？
• 就功能/工作量比和可维护性而言，它们是否是一个好的设计选择？

非常感谢有关此主题的任何示例/讨论的链接。谢谢。

Answer 1

是的，我对一般的可更新 View 有一些经验。我认为它们在 PostgreSQL 中很实用。与所有设计选择一样，它们可以是好的选择，也可以是坏的选择。

我发现它们在处理父类(super class)型/子类型表时特别有用。我为每个子类型创建一个 View ；该 View 将子类型连接到父类(super class)型。撤销对基表的权限，为 View 编写规则，并仅授予客户端代码对 View 的访问权限。客户端代码完成的所有数据操作然后通过 View 和在它们上定义的规则。

我认为规则与任何其他环境中的任何其他功能并没有真正的不同。我所说的环境是指 C、C++、Java、Ruby、Python、Erlang 和 BASIC，而不仅仅是 dbms 环境。

利用语言的优点。避免坏的。

“不要使用 malloc()”是个糟糕的建议。 “始终检查 malloc() 的返回值”是个好建议。 “永远不要使用规则”是个糟糕的建议。 “避免以已知具有可疑行为的方式使用规则”是一个很好的建议。父类(super class)型/子类型 TableView 所需的规则简单易懂。他们不会行为不端。

在理论层面， View 提供逻辑数据独立性。但这只有在 View 可更新时才有可能。 (而且许多 View 应该可以直接由数据库引擎更新，而不需要任何规则或触发器。)