可修改的连接视图是一个合理的设计选择吗？

Question

要明确，通过可修改加入视图我的意思是通过连接两个或多个表构建的视图，允许插入/更新/删除操作来修改任何/所有组件表。

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

我正在开发一个postgres架构，我最近的一些阅读建议可以使用规则（CREATE RULE ... DO INSTEAD ...）构建可修改的连接视图。可修改的连接视图似乎是可取的，因为它允许在接口后面隐藏强规范化，提供经典抽象的机制。规则是实施的唯一选择，因为目前triggers cannot be set on views。

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

问题（编辑以在问题上加上更好的分数）：

• 您是否有使用可修改的连接视图的经验，是否可以提供具有选择/插入/删除/更新功能的具体示例？
• 它们是否实用，即它们是否可以透明地处理而不必在矿井/黑洞周围tip脚？
• 在功能/工作量和可维护性方面，它们是否是一个很好的设计选择？

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

Answer 1

是的，我对一般的可更新视图有一些经验。我认为它们在PostgreSQL中很实用。像所有设计选择一样，它们可能是一个不错的选择，而且它们可能是一个糟糕的选择。

我发现它们在处理超类型/子类型表时特别有用。我为每个子类型创建一个视图;视图将子类型连接到超类型。撤消对基表的权限，为视图编写规则，并仅授予客户端代码访问视图的权限。然后，客户端代码完成的所有数据操作都将通过视图和在其上定义的规则进行。

我认为规则与任何其他环境中的任何其他功能都不相同。通过 environment ，我指的是C，C ++，Java，Ruby，Python，Erlang和BASIC，而不仅仅是dbms环境。

使用语言的优点。避免坏事。

“不要使用malloc（）”是不好的建议。 “总是检查malloc（）的返回值”是个好建议。 “从不使用规则”是不好的建议。 “避免以已知有可疑行为的方式使用规则”是一个好建议。对于超类型/子类型表的视图所需的规则简单易懂。他们没有行为不端。

在理论层面，视图提供逻辑数据独立性。但只有在视图可更新的情况下才有可能。 （许多视图应该可以由数据库引擎直接更新，而不需要任何规则或触发器。）

Answer 2

我用它们作为ORM的替代品。我认为，只要你不通过数据库将它们洒到各处，它们就可以很容易理解。我为应用程序定义了一个模式，然后该模式中的任何视图都是该应用程序的方法和操作。之后客户端代码可以大部分自动化，因为视图提供了编写通用客户端代码所需的抽象。

人们指出规则重写不是一个真正的表（但它是一个冒充），这使得编写可能破坏的东西成为可能。这是可能的，但我还没有遇到它。我们的想法是隐藏重写的复杂性，然后只进行简单的删除并使用 no join 进行更新。如果事实证明需要加入 - 是时候重写规则，而不是顶级查询。

最后，我发现它是一种非常紧凑的编写数据库的方法。与它连接的所有方式都是作为规则编写的。没有连接应该可以访问真实的表。您的业​​务逻辑非常明确。如果视图没有针对它的UPDATE规则 - 则无法更新周期。由于您已在数据库级别而不是客户端级别编写了所有这些内容，因此它不依赖于Web框架或特定语言。这为您希望连接数据库提供了很大的灵活性。想象一下，您使用了Web框架，但随着时间的推移，您需要直接访问数据库以获取其他来源。直接访问还将绕过您努力工作的所有ORM业务规则。使用规则编写接口，您可以公开接口，而不必担心新连接会破坏数据。

如果有人说你真的可以用它们建立一个数据库 - 那么当然可以 - 当然你可以。但你也可以和其他一切一样。如果人们说你根本不能使用它们，那么我就不同意了。

Answer 3

两个快速链接：

1. Why using rules is bad idea
2. Triggers on views

Answer 4

我个人的偏好是仅使用视图来读取数据，（实际上）从不插入或更新。通过在数据库中基本上重新规范数据（听起来就像你正在做的那样），你可能会创建一个很难长期测试和维护的系统。

如果可能，请查看将非规范化数据映射回应用程序代码中某处的正常模式，并在单个事务中以相应方式（对于单个表IMHO）将其提供给数据库。

Answer 5

我知道在SQL Server中，如果你更新一个视图，你必须将更改限制为只有一个表，这使得使用视图进行更新在我脑海中无用，因为你必须知道哪些字段与哪些表一起使用。

如果要抽出信息而不必担心插入和更新的数据库结构，ORM mught为您做的比视图更好。

Answer 6

我从未使用任何类型的可修改视图，但是当您询问它们是否是“合理的设计选择”时，我是否可以建议一种替代设计选择，其中包含不需要可修改视图的许多好处：Transactional API

基本上这相当于：

• 用户无权访问表格，无法发布insert，update，delete语句
• 用户可以访问代表明确定义的事务的函数 - 在最简单的级别，这些函数可能只执行一个DML，但通常不会。重要的是，它们映射到“业务”意义上的交易而不是“数据库”意义上的交易
• 对于查询，用户可以访问（不可修改的）视图

Answer 7

我通常会以“最后有效记录”的形式进行观看，只是隐藏和跟踪修改（如维基） 我看到的唯一缺点是：然后你将你的视图用作一个表，并将它与任何东西一起加入，并且你在“wheres”上使用它，并在其上插入记录，依此类推，但在你身后与针对真实桌子的相同操作（更大更复杂）相比，性能损失很多。我认为这取决于有多少人必须低估模式。确实有些DBMS也承认对视图进行索引，但我认为你无论如何都会失去重要的性能。抱歉我的英文。