这可能是一个postgres特定的问题,不确定.我也感兴趣,如果其他DBMS具有可修改的连接视图的特殊功能,因为据我所知,它们在标准sql中是不可能的.
我正在研究一个postgres模式,我最近的一些阅读建议可以使用替代规则构建可修改的连接视图(CREATE RULE … DO INSTEAD …).可修改的连接视图似乎是可取的,因为它允许在接口后面隐藏强规范化,提供经典抽象的机制.规则是实施的唯一选择,因为目前为triggers cannot be set on views.
然而,我尝试设计的第一个可修改的视图遇到了问题,我发现很多人认为非平凡的规则是有害的(参见this SO answer评论中的链接).另外,我在网上找不到任何可修改的连接视图的例子.
问题(编辑以在问题上提出更好的观点)：
>您是否有使用可修改的连接视图的经验,是否可以提供具有选择/插入/删除/更新功能的具体示例？
>它们是否实用,即它们是否可以透明地处理而不必tip着脚尖/黑洞？
>在功能/工作量和可维护性方面,它们是否是一个很好的设计选择？
我发现它们在处理超类型/子类型表时特别有用.我为每个子类型创建一个视图;视图将子类型连接到超类型.撤消对基表的权限,为视图编写规则,并仅授予客户端代码访问视图的权限.然后,客户端代码完成的所有数据操作都将通过视图和在其上定义的规则进行.
我认为规则与其他任何环境中的任何其他功能都不相同.环境方面,我指的是C,C,Java,Ruby,Python,Erlang和BASIC,而不仅仅是dbms环境.
使用语言的好功能.避免坏的.
“不要使用malloc()”是不好的建议. “总是检查malloc()的返回值”是个好建议. “从不使用规则”是不好的建议. “避免以已知有可疑行为的方式使用规则”是一个好建议.对于超类型/子类型表的视图所需的规则简单易懂.他们没有行为不端.
在理论层面,视图提供逻辑数据独立性.但只有在视图可更新的情况下才有可能. (许多视图应该可以由数据库引擎直接更新,而不需要任何规则或触发器.)
