可修改的連接視圖是否合理的設計選擇？

Question

要清楚，通過可修改加入查看我的意思是從兩個或多個表的連接構造的視圖，允許插入/更新/刪除操作，修改任何/所有的組件表。

這可能是一個Postgres的具體問題，不知道。如果其他DBMS具有可修改連接視圖的特殊功能，我也感興趣，因爲據我所知，它們在標準SQL中是不可能的。

我正在研究一個postgres模式，並且我最近的一些閱讀建議可以使用替代規則構建可修改的聯接視圖（CREATE RULE ... DO INSTEAD ...）。可修改的連接視圖似乎是可取的，因爲它允許在接口後面隱藏強大的規範化，爲經典抽象提供了機制。規則是實施的唯一選擇，因爲目前爲triggers cannot be set on views。

但是，我試圖設計的第一個可修改視圖遇到了問題，我發現許多人認爲非平凡規則是有害的（請參閱this SO answer的評論中的鏈接）。另外，我在網上找不到任何可修改的連接視圖的例子。

問題（編輯提上問題較細分）：

• 你有修改的連接視圖中，您可以提供選擇/插入一個具體的例子任何經驗/刪除/更新的能力？
• 它們是否具有實用性，即它們是否可以透明地處理而不必在礦井/黑洞周圍tip手？腳？
• 在功能/努力率和可維護性方面，它們是否曾經是一個很好的設計選擇？

將不勝感激鏈接到關於這個主題的例子/討論。謝謝。

Answer 1

我個人的偏好是使用意見僅讀取數據，（幾乎）從不插入或更新。通過對數據庫中的數據進行重新規範化（這聽起來像是您正在做的事情），您可能會創建一個長期難以測試和維護的系統。

如果可能的話，請查看將您的非規格化數據映射回應用程序代碼中某處的正常模式，並在單個事務中以這種方式將數據提供給單個表（恕我直言）。

Answer 2

我把它們作爲的ORM的替代品。我認爲，只要你不會在數據庫的任何地方灑滿他們，他們可以很容易理解。我爲應用程序定義了一個模式，然後該模式中的任何視圖都是該應用程序的方法和操作。之後客戶端代碼可以大部分是自動的，因爲視圖提供了我需要編寫通用客戶端代碼的抽象。

人士指出，該規則重寫不是一個真正的表（但冒充一個），這使得它可以寫的東西會打破。這是可能的，但我還沒有碰到它。這個想法是隱藏在重寫中的複雜性，然後只做簡單的刪除和更新沒有加入。如果事實證明需要加入 - 現在是重寫規則的時候了，而不是頂級查詢。

最後，我發現這是一個非常緊湊的方式來寫數據庫。所有與它接口的方式都是作爲規則書寫的。沒有連接應該可以訪問真正的表格。您的業​​務邏輯非常明確。如果一個視圖沒有UPDATE規則 - 它不能被更新。由於您已將所有這些內容寫入數據庫級別而不是客戶端級別，因此不會綁定到Web框架或特定語言。這導致您想要連接到數據庫的方式具有很大的靈活性。想象一下你使用了web框架，但隨着時間的推移，你需要直接訪問另一個數據庫的數據庫。直接訪問也將繞過您所有努力工作的所有ORM業務規則。使用可以公開的規則編寫接口，接口無需擔心新連接會破壞數據。

如果有人說你真的可以用他們的數據庫 - 然後確定 - 當然你可以。但你也可以與其他一切。如果有人說你根本無法使用它們，那麼我會不同意。

Answer 3

我知道在SQL Server中，如果更新視圖，您必須將更改限制爲只有一個表，無論如何，這使得使用視圖更新無用在我的腦海中，因爲您必須知道哪些字段與哪些表一起使用。

如果您想抽象出信息，而不必擔心插入和更新的數據庫結構，ORM mught對您的幫助比視圖更好。

Answer 4

兩個快速鏈接：

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

Answer 5

是的，我有一般的可更新視圖的一些經驗。我認爲他們在PostgreSQL中很實用。像所有的設計選擇一樣，它們可以是一個不錯的選擇，而且它們可能是一個不好的選擇。

我發現它們在處理超類型/子類型表格時特別有用。我爲每個子類型創建一個視圖;該視圖將子類型連接到超類型。撤銷對基表的權限，爲視圖編寫規則，並僅允許客戶端代碼訪問視圖。客戶端代碼完成的所有數據操作都會通過視圖和在其上定義的規則。

我不認爲規則與任何其他環境中的任何其他功能真的不同。而通過環境，我的意思是C，C++，Java，Ruby，Python，Erlang和BASIC，而不僅僅是dbms環境。

使用語言的良好功能。避免壞的。

「不要使用malloc（）」是不好的建議。 「總是檢查malloc（）的返回值」是很好的建議。 「不要使用規則」是不好的建議。 「避免以已知有可疑行爲的方式使用規則」是很好的建議。您需要的有關超類型/子類型表的視圖規則很簡單，易於理解。他們不會行爲不端。

在理論層面上，視圖提供邏輯數據獨立性。但只有在視圖可更新的情況下才有可能。 （許多視圖應該可以直接由數據庫引擎更新，而不需要任何規則或觸發器。）

Answer 6

我從來沒有使用任何形式的修改意見，但因爲你是問他們是否是一個「合理的設計選擇」，我可以建議的替代設計選擇有很多好處在不需要修改意見：一Transactional API

基本上什麼這相當於是：

• 用戶必須對錶沒有訪問權限，不能發出insert，update，在所有
• 用戶delete陳述必須根據函數represen訪問定義明確的交易 - 在最簡單的層面上，這些可能只是單個DML，但通常不會。最重要的是，它們映射到交易的「生意」的意義而不是在「數據庫」感
• 用於查詢，用戶可以訪問（不可修改）的意見

Answer 7

我平時做的意見以「最後有效記錄」的形式進行隱藏和跟蹤修改（例如維基）
我看到的唯一缺點是：然後將視圖用作表格，然後將其與任何內容結合使用，並且並且你在「wheres」上使用它，並在其上插入記錄等等，但是相比於對真實表格（更大更復雜）的相同操作，你已經失去了很多性能。我認爲這取決於有多少人必須理解模式。確實，一些DBMS也承認對這些觀點進行索引，但我認爲你無論如何都會失去一大筆業績。對不起我的英語。