https://www.yiibai.com/mysql/introduction-sql-views.html

檢視

使用資料庫檢視的優點

資料庫檢視允許簡化複雜查詢：資料庫檢視由與許多基礎表相關聯的SQL語句定義。
您可以使用資料庫檢視來隱藏終端使用者和外部應用程式的基礎表的複雜性。
通過資料庫檢視，您只需使用簡單的SQL語句，而不是使用具有多個連線的複雜的SQL語句。

資料庫檢視有助於限制對特定使用者的資料訪問。 您可能不希望所有使用者都可以查詢敏感資料的子集。可以使用資料庫檢視將非敏感資料僅顯示給特定使用者組。

資料庫檢視提供額外的安全層。 安全是任何關係資料庫管理系統的重要組成部分。 資料庫檢視為資料庫管理系統提供了額外的安全性。
資料庫檢視允許您建立只讀檢視，以將只讀資料公開給特定使用者。 使用者只能以只讀檢視檢索資料，但無法更新。

資料庫檢視啟用計算列。 資料庫表不應該具有計算列，但資料庫檢視可以這樣。
假設在orderDetails表中有quantityOrder(產品的數量)和priceEach(產品的價格)列。
但是，orderDetails表沒有一個列用來儲存訂單的每個訂單項的總銷售額。如果有，資料庫模式不是一個好的設計。
在這種情況下，您可以建立一個名為total的計算列，該列是quantityOrder和priceEach的乘積，以表示計算結果。當您從資料庫檢視中查詢資料時，計算列的資料將隨機計算產生。

資料庫檢視實現向後相容。 假設你有一箇中央資料庫，許多應用程式正在使用它。
有一天，您決定重新設計資料庫以適應新的業務需求。刪除一些表並建立新的表，並且不希望更改影響其他應用程式。在這種情況下，可以建立與將要刪除的舊錶相同的模式的資料庫檢視。

資料庫檢視的缺點

除了上面的優點，使用資料庫檢視有幾個缺點：

效能：從資料庫檢視查詢資料可能會很慢，特別是如果檢視是基於其他檢視建立的。
表依賴關係：將根據資料庫的基礎表建立一個檢視。每當更改與其相關聯的表的結構時，都必須更改檢視。

https://www.yiibai.com/mysql/introduction-to-sql-stored-procedures.html

儲存過程

MySQL儲存過程的優點

通常儲存過程有助於提高應用程式的效能。當建立，儲存過程被編譯之後，就儲存在資料庫中。 但是，MySQL實現的儲存過程略有不同。
MySQL儲存過程按需編譯。 在編譯儲存過程之後，MySQL將其放入快取中。 MySQL為每個連線維護自己的儲存過程快取記憶體。
如果應用程式在單個連線中多次使用儲存過程，則使用編譯版本，否則儲存過程的工作方式類似於查詢。
儲存過程有助於減少應用程式和資料庫伺服器之間的流量，因為應用程式不必傳送多個冗長的SQL語句，而只能傳送儲存過程的名稱和引數。
儲存的程式對任何應用程式都是可重用的和透明的。 儲存過程將資料庫介面暴露給所有應用程式，以便開發人員不必開發儲存過程中已支援的功能。
儲存的程式是安全的。 資料庫管理員可以向訪問資料庫中儲存過程的應用程式授予適當的許可權，而不向基礎資料庫表提供任何許可權。
除了這些優點之外，儲存過程有其自身的缺點，在資料庫中使用它們之前，您應該注意這些缺點。

MySQL儲存過程的缺點

如果使用大量儲存過程，那麼使用這些儲存過程的每個連線的記憶體使用量將會大大增加。
此外，如果您在儲存過程中過度使用大量邏輯操作，則CPU使用率也會增加，因為資料庫伺服器的設計不當於邏輯運算。
儲存過程的構造使得開發具有複雜業務邏輯的儲存過程變得更加困難。
很難除錯儲存過程。只有少數資料庫管理系統允許您除錯儲存過程。不幸的是，MySQL不提供除錯儲存過程的功能。
開發和維護儲存過程並不容易。開發和維護儲存過程通常需要一個不是所有應用程式開發人員擁有的專業技能。這可能會導致應用程式開發和維護階段的問題。

MySQL儲存過程有自己的優點和缺點。開發應用程式時，您應該決定是否應該或不應該根據業務需求使用儲存過程

http://www.cnblogs.com/fuland/p/4280434.html

外來鍵

主鍵和索引是不可少的，不僅可以優化資料檢索速度，開發人員還省不其它的工作,

矛盾焦點：資料庫設計是否需要外來鍵。這裡有兩個問題：一個是如何保證資料庫資料的完整性和一致性；二是第一條對效能的影響。

正方觀點：

1，由資料庫自身保證資料一致性，完整性，更可靠，因為程式很難100％保證資料的完整性，而用外來鍵即使在資料庫伺服器當機或者出現其他問題的時候，也能夠最大限度的保證資料的一致性和完整性。
eg：資料庫和應用是一對多的關係，Ａ應用會維護他那部分資料的完整性，系統一變大時，增加了Ｂ應用，Ａ和Ｂ兩個應用也許是不同的開發團隊來做的。他們如何協調保證資料的完整性，而且一年以後如果又增加了C應用呢？
2，有主外來鍵的資料庫設計可以增加ER圖的可讀性，這點在資料庫設計時非常重要。 3，外來鍵在一定程度上說明的業務邏輯，會使設計周到具體全面。

反方觀點：

1，可以用觸發器或應用程式保證資料的完整性 2，過分強調或者說使用主鍵／外來鍵會平添開發難度，導致表過多等問題 3，不用外來鍵時資料管理簡單，操作方便，效能高（匯入匯出等操作，在insert, update, delete 資料的時候更快）
eg:在海量的資料庫中想都不要去想外來鍵，試想，一個程式每天要insert數百萬條記錄，當存在外來鍵約束的時候，每次要去掃描此記錄是否合格，一般還不
止一個欄位有外來鍵，這樣掃描的數量是成級數的增長！我的一個程式入庫在3個小時做完，如果加上外來鍵，需要28個小時！

結論： 1，在大型系統中（效能要求不高，安全要求高），使用外來鍵；在大型系統中（效能要求高，安全自己控制），不用外來鍵；小系統隨便，最好用外來鍵。
2，用外來鍵要適當，不能過分追求 3，不用外來鍵而用程式控制資料一致性和完整性時，應該寫一層來保證，然後個個應用通過這個層來訪問資料庫。

需要注意的是：MySQL允許使用外來鍵，但是為了完整性檢驗的目的，在除了InnoDB表型別之外的所有表型別中都忽略了這個功能。這可能有些怪異，實際上卻非常正常：對於資料庫的所有外來鍵的每次插入、更新和刪除後，進行完整性檢查是一個耗費時間和資源的過程，它可能影響效能，特別是當處理複雜的或者是纏繞的連線樹時。因而，使用者可以在表的基礎上，選擇適合於特定需求的最好結合。所以，如果需要更好的效能，並且不需要完整性檢查，可以選擇使用MyISAM表型別，如果想要在MySQL中根據參照完整性來建立表並且希望在此基礎上保持良好的效能，最好選擇表結構為innoDB型別

https://www.yiibai.com/mysql/sql-triggers.html

觸發器

SQL觸發器的優點

SQL觸發器提供了檢查資料完整性的替代方法。 SQL觸發器可以捕獲資料庫層

中業務邏輯中的錯誤。
SQL觸發器提供了執行計劃任務的另一種方法。通過使用SQL觸發器，您不必等待執行計劃的任務，因為在對錶中的資料進行更改之前或之後自動呼叫觸發器。
SQL觸發器對於稽核表中資料的更改非常有用。

SQL觸發器的缺點

SQL觸發器只能提供擴充套件驗證，並且無法替換所有驗證。一些簡單的驗證必須在應用層完成。
例如，您可以使用JavaScript或伺服器端使用伺服器端指令碼語言(如JSP，PHP，ASP.NET，Perl等)來驗證客戶端的使用者輸入。
從客戶端應用程式呼叫和執行SQL觸發器不可見，因此很難弄清資料庫層中發生的情況。 SQL觸發器可能會增加資料庫伺服器的開銷。
可能造成死鎖