視圖，對於數據庫來說，是一個最基本的、也是最重要的功能之一。數據庫視圖設計的好壞，直接跟數據庫的性能相關。而且，在大型數據庫設計中，大家分工合作，基礎表的設計與報表視圖的設計往往由不同的人負責。所以，視圖的設計管理跟基礎表的設計管理一樣，都有很大的學問。
技巧一：把基礎表與視圖脫離開來。
一般來說，視圖都是在基礎表的上面建立起來的。也就是說，要先有基礎表，而後有視圖。但是，在大型數據庫的設計過程中，出於項目時間的考慮，往往基礎表與視圖的設計是同時進行的。如一些人負責基礎表的建立，另一些人則負責視圖的設計與建立等等。在這個過程中，往往基礎表不存在的時候，就需要建立一些視圖，以加快項目的進度。
爲了使得基礎表的創建和修改與視圖的創建於修改沒有必然的聯繫，以便於員工之間工作的同步，提高工作效率，所以，在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開頭，跟基礎表進行隔開;另外在視圖命名中，能夠根據應用模塊的不同，來進行分類，並體現在視圖的名字中。這對於我們後續視圖的查找都具有非常現實的意義。二是雖然可以在視圖中直接更新基礎表，不過，爲了安全與數據統一的考慮，我們這些過來人一般都不建議通過視圖來直接更新基礎表中的數據。雖然數據庫提供了類似的功能。若要更改相關數據的話，則直接去更改基礎表的內容爲好。在建立視圖的時候，默認情況下是不能夠通過視圖直接更新基礎表。
