檢視，對於資料庫來說，是一個最基本的、也是最重要的功能之一。資料庫檢視設計的好壞，直接跟資料庫的效能相關。而且，在大型資料庫設計中，大家分工合作，基礎表的設計與報表檢視的設計往往由不同的人負責。所以，檢視的設計管理跟基礎表的設計管理一樣，都有很大的學問。
技巧一：把基礎表與檢視脫離開來。
一般來說，檢視都是在基礎表的上面建立起來的。也就是說，要先有基礎表，而後有檢視。但是，在大型資料庫的設計過程中，出於專案時間的考慮，往往基礎表與檢視的設計是同時進行的。如一些人負責基礎表的建立，另一些人則負責檢視的設計與建立等等。在這個過程中，往往基礎表不存在的時候，就需要建立一些檢視，以加快專案的進度。
為了使得基礎表的建立和修改與檢視的創建於修改沒有必然的聯絡，以便於員工之間工作的同步，提高工作效率，所以，在Oracle資料庫中提出了一個“強制建立檢視”的概念。也就是說，正常情況下，如果基本表不存在，則建立檢視就會失敗。但是，我們可以在建立檢視的過程中，加入一個引數，只要建立檢視的語法沒有錯誤的話，即使基礎表不存在，仍然可以建立這張表格。這個有用的引數就是force選項。如我們建立檢視時，CREATE FORCE VIEW TEXT，只需要在關鍵字VIEW之前加入FORCE引數即可。如此的話，系統在編譯檢視的時候，就不會去考慮基礎表是否存在。
不過這裡要注意一點，若基礎表不存在的話，則編譯後該檢視的狀態為“無效”，不能再這個檢視的基礎上執行一些操作，如查詢操作等等。當下次訪問這個檢視的時候，則資料庫會對這個檢視進行重新編譯，若此時基礎表存在了，則該基礎表就會變為有效;若基礎表不存在，則這檢視就會失效。
Oracle資料庫之所以如此設定，主要是出於在資料庫設計過程中協同辦公的需要。有了這個功能之後，則在資料庫建立的過程中，只要把資料庫基礎表與檢視設計好之後，大家就可以分工合作，在資料庫中建立相關的物件。不然的話，要等基礎表建立好之後再建立檢視，如此就會明顯的影響資料庫建立的進度。所以，在資料庫建立的過程中，特別是中大型的資料庫系統，這是一個很實用的功能。
技巧二：建立檢視的理想步驟。
無論是簡單檢視，還是比較複雜的檢視，筆者覺得資料庫管理員在建立檢視的時候，最好能夠遵循一定的步驟。這一方面是因為檢視的更改相對來說，是一件比較麻煩的工作，所以，我們在建立檢視的時候，要確保檢視的準確性。另一方面，檢視是基礎表的一個體現形式，若不按步驟來做的話，有可能就不能夠達到我們預計的需求。
當然這個步驟沒有官方的版本，完全是資料庫管理員根據實際的經驗總結出來的。這個步驟不僅對Oracle資料庫有效，對於其他資料庫來說，也是類似的道理。
一般來說，檢視建立可以分為五步走，
第一步：先考慮Select語句的編寫。
我們知道，檢視其實就是一個Select語句的集合。所以，我們建立檢視的第一步，就是考慮這個Select語句該如何編寫。這個Select語句編寫的是否合理、執行效率的高低直接影響著這個檢視的效能。另外，在Select語句中，可能還會有格式的控制、內容的編排等等。如在Select語句中，可以把一些欄位合併成一個欄位;也可以把相關的內容進行倒置等等。這些功能都是Select語句完成的。所以可以這麼說，Select語句的編寫是檢視建立的基礎。
第二步：對這個Select語句進行測試。
當我們編寫好Select語句之後，就需要在資料庫中執行這條語句，看其能否查詢到我們想要的值。在對Select語句進行測試的時候，需要注意一個問題，有時候Select查詢語句可以查到準確的資料，但是在以這條語句建立檢視的時候，可能就會通不過。如在一些表之間的`連線查詢的時候，如果兩個表中有個欄位名相同，是可以的。因為他們除了欄位名字之外，還有表名一起來定義這個欄位。如與。這是不算重名的。但是，若在建立檢視的時候，這就會被認為是重複的列明，需要對其中的一個列名進行重定義。這一點在資料庫檢視建立的時候，要特別的注意。
第三步：考慮查詢結果的準確性。
通過查詢語句把我們想要的結果查詢出來後，我們就需要看看這個結果是否滿足我們的需要。在這個過程中，我們主要注意兩點。一是形式欄位是否齊全。在一些應用系統中，若資料庫的檢視要能夠被前臺的應用程式呼叫的話，則必須包含一些形式欄位。如筆者以前在設計一個ERP系統的時候，若前臺系統要呼叫資料庫中的檢視的時候，必須包含記錄更新時間、更新者、記錄建立時間、建立者等相關資訊。若缺乏這些資訊的話，則前臺呼叫這張檢視的時候，就會出現錯誤。故在考慮查詢結果準確性的問題的時候，就要考慮到前臺應用程式的需要，看看這些形式欄位是否齊全。二是實體內容的完整性。我們到底需要顯示錶中的哪些欄位呢，這個我們在這裡要確認清楚。若顯示內容太多的話，則會影響檢視的執行效率，而且也會降低檢視的安全性作用;但是，若欄位內容顯示不足的話，則以後要新增欄位的話，會比較麻煩，有一定的工作量。所以在這個檢驗的時候，需要根據檢視的實際功用，確定檢視需要顯示的內容。
第四步：檢視的修飾。
有時候，為了閱讀的方便，我們需要對查詢結果進行一些修飾。如現在有兩張表，一張是員工基本資訊表，這表中有員工姓名、員工職位編號等等;另一張表是職位基本資訊表，在這表中有職位編號、職位名稱。我們希望在檢視中能夠如下顯示：“職位：員工名字”，如資料庫工程師：Victor。也就是說，把兩個欄位合併起來，並且在中間加入一個冒號。這些格式性的內容都是在查詢的時候實現的。所以，我們確認查詢的結果沒有錯誤之後，接下來就要確認格式問題。若能夠在檢視中規範這些格式問題，則前臺的程式設計就會相對來說比較簡單。
第五步：建立檢視。
等到上面四步都確認無誤後，我們就要根據上面的查詢語句來建立檢視了。不過在這一步過程中，也有一些問題需要注意。一是檢視名字的命名規格。我們除了遵循資料庫的強制命名格式之外，如不能以數字開頭等等，還需要遵循一些軟規則。如檢視最好能夠以V開頭，跟基礎表進行隔開;另外在檢視命名中，能夠根據應用模組的不同，來進行分類，並體現在檢視的名字中。這對於我們後續檢視的查詢都具有非常現實的意義。二是雖然可以在檢視中直接更新基礎表，不過，為了安全與資料統一的考慮，我們這些過來人一般都不建議通過檢視來直接更新基礎表中的資料。雖然資料庫提供了類似的功能。若要更改相關資料的話，則直接去更改基礎表的內容為好。在建立檢視的時候，預設情況下是不能夠通過檢視直接更新基礎表。
