一、使用視圖的理由是什么？
1.安全性。一般是這樣做的:創(chuàng)建一個(gè)視圖，定義好該視圖所操作的數(shù)據(jù)。之后將用戶權(quán)限與視圖綁定。這樣的方式是使用到

了一個(gè)特性：grant語句可以針對(duì)視圖進(jìn)行授予權(quán)限。
2.查詢性能提高。

3.有靈活性的功能需求后，需要改動(dòng)表的結(jié)構(gòu)而導(dǎo)致工作量比較大。那么可以使用虛擬表的形式達(dá)到少修改的效果。

這是在實(shí)際開發(fā)中比較有用的

例子：假如因?yàn)槟撤N需要，a表與b表需要進(jìn)行合并起來組成一個(gè)新的表c。最后a表與b表都不會(huì)存在了。而由于原來程序中編

寫sql分別是基于a表與b表查詢的，這就意味著需要重新編寫大量的sql(改成向c表去操作數(shù)據(jù))。而通過視圖就可以做到不修

改。定義兩個(gè)視圖名字還是原來的表名a和b。a、b視圖完成從c表中取出內(nèi)容。

說明：使用這樣的解決方式，基于對(duì)視圖的細(xì)節(jié)了解越詳細(xì)越好。因?yàn)槭褂靡晥D還是與使用表的語法上沒區(qū)別。比如視圖名a
，那么查詢還是"select * from a"。

4.復(fù)雜的查詢需求。可以進(jìn)行問題分解，然后將創(chuàng)建多個(gè)視圖獲取數(shù)據(jù)。將視圖聯(lián)合起來就能得到需要的結(jié)果了。



視圖的工作機(jī)制:當(dāng)調(diào)用視圖的時(shí)候，才會(huì)執(zhí)行視圖中的sql，進(jìn)行取數(shù)據(jù)操作。視圖的內(nèi)容沒有存儲(chǔ)，而是在視圖被引用的時(shí)候才派生出數(shù)據(jù)。這樣不會(huì)占用空間，由于是即時(shí)引用，視圖的內(nèi)容總是與真實(shí)表的內(nèi)容是一致的。

視圖這樣設(shè)計(jì)有什么好處？節(jié)省空間，內(nèi)容是總是一致的話，那么我們不需要維護(hù)視圖的內(nèi)容，維護(hù)好真實(shí)表的內(nèi)容，就可以保證視圖的完整性了。

二、通過更新視圖實(shí)現(xiàn)更新真實(shí)表

看到很多例子，更新視圖可以更新真實(shí)表。原因，我是這樣理解的：視圖并沒有保存內(nèi)容。只是引用數(shù)據(jù)。那么，更新視圖，其實(shí)就是以引用的方式操作了真實(shí)表
with check option：對(duì)視圖進(jìn)行更新操作的時(shí)，需要檢查更新后的值是否還是滿足視圖公式定義的條件。通俗點(diǎn)，就是所更新的結(jié)果是否還會(huì)在視圖中存在。如果更新后的值不在視圖范圍內(nèi)，就不允許更新如果創(chuàng)建視圖的時(shí)候，沒有加上with check option，更新視圖中的某項(xiàng)數(shù)據(jù)的話，mysql并不會(huì)進(jìn)行有效性檢查。刪掉了就刪掉了。在視圖中將看不到了。


使用有效性檢查，實(shí)際意義是什么？


視圖的實(shí)踐：重新組織表的需求
CREATE TABLE `result` (`MATH_NO` INT(10) NOT NULL unsigned AUTO_INCREMENT PRIMARY KEY,
`TEAMNO` INT(10) NOT NULL,
`PLAYERNO` INT(10) NOT NULL,
`WON` VARCHAR(10) NOT NULL,
`LOST` VARCAHR(10) NOT NULL,
`CAPTAIN` INT(10) NOT NULL COMMIT '就是PLAYERNO的另外名字',
`DIVISION` VARCHAR(10) NOT NULL
) ENGINE=MYISAM? DEFAULT CHARSET=utf8 COMMIT='重新組的新表' AUTO_INCREMENT=1


針對(duì)每個(gè)表創(chuàng)建一個(gè)視圖，將數(shù)據(jù)保存進(jìn)去：
CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION) AS SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result

報(bào)錯(cuò)：#1050 - Table 'teams' already exists

說明，因?yàn)橐晥D也是一種表，是虛擬表。不能與已有的表(視圖)出現(xiàn)重名

接下來，刪掉表teams，再執(zhí)行創(chuàng)建視圖的代碼。


將視圖看成與表一樣的東西，更加容易理解使用規(guī)則。下面這樣對(duì)比也許使自己更好理解：

1.在使用視圖的時(shí)候，就是與使用表的語法一樣的。
2.創(chuàng)建視圖的時(shí)候，該視圖的名字如果與已經(jīng)存在表重名的話，那么會(huì)報(bào)錯(cuò)，不允許創(chuàng)建。視圖就是一種特殊的表

3.創(chuàng)建視圖的時(shí)候，可以這樣使用CREATE VIEW teams(TEAMNO,PLAYERNO,DIVISION)，可以定義視圖表的結(jié)構(gòu)。
4.在phpmyadmin中。左邊的表列表中將視圖與表列在了一起。只有通過右側(cè)的狀態(tài)"View:teams"可以知道該表是視圖表。



視圖在mysql中的內(nèi)部管理機(jī)制:

視圖的記錄都保存在information_schema數(shù)據(jù)庫中的一個(gè)叫views的表中。具體某個(gè)視圖的定義代碼以及屬于哪個(gè)數(shù)據(jù)庫等信息可以從里面看到理解視圖的兩種工作機(jī)制：

語句：select * from teams

針對(duì)上面語句，總結(jié)幾個(gè)知識(shí)點(diǎn)
1.確認(rèn)是視圖的過程：teams也可以是表名。由于表與視圖的物理機(jī)制不同。視圖本身是不存儲(chǔ)內(nèi)容的。所以，在使用sql的
時(shí)候，mysql是怎么知道teams是一個(gè)視圖還是表。是因?yàn)橛幸粋€(gè)查看目錄的例程在做這件事。

2.mysql對(duì)處理視圖的兩種方法：替代方式和具體化方式。
替換方式理解，視圖名直接使用視圖的公式替換掉了。針對(duì)上面視圖teams，mysql會(huì)使用該視圖的公式進(jìn)行替換，視圖公式合并到了select中。結(jié)果就是變成了如下sql語句：
select * from (SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result)。也就是最后提交給mysql處理該sql語句。


具體化方式理解，mysql先得到了視圖執(zhí)行的結(jié)果，該結(jié)果形成一個(gè)中間結(jié)果暫時(shí)存在內(nèi)存中。之后，外面的select語句就調(diào)

用了這些中間結(jié)果(臨時(shí)表)。


看起來都是要得到結(jié)果，形式上有區(qū)別，好像沒體會(huì)到本質(zhì)上的區(qū)別。兩種方式又有什么樣的不同呢？

替換方式，將視圖公式替換后，當(dāng)成一個(gè)整體sql進(jìn)行處理了。具體化方式，先處理視圖結(jié)果，后處理外面的查詢需求。
替換方式可以總結(jié)為，先準(zhǔn)備，后執(zhí)行。
具體化方式總結(jié)理解為，分開處理。

哪種方式好？不知道。mysql會(huì)自己確定使用哪種方式進(jìn)行處理的。自己在定義視圖的時(shí)候也可以指定使用何種方式。像這樣

使用：

CREATE ALGORITHM=merge VIEW teams as SELECT? DISTINCT TEAMNO,CAPTAIN,DIVISION FROM result

ALGORITHM有三個(gè)參數(shù)分別是：merge、TEMPTABLE、UNDEFINED

看mysql手冊(cè)中提到，替換與具體化的方式的各自適用之處，可以這樣理解：
因?yàn)榕R時(shí)表中的數(shù)據(jù)不可更新。所以，如果使用參數(shù)是TEMPTABLE，無法進(jìn)行更新。
當(dāng)你的參數(shù)定義是UNDEFINED(沒有定義ALGORITHM參數(shù))。mysql更傾向于選擇合并方式。是因?yàn)樗佑行А?

mysql視圖學(xué)習(xí)總結(jié)