一定會用.
當資料連經過3NF後, 一定會要用View把關聯的資料串在一起, 以便前端Forms(Winform、Webform)的設計, 不論這個View是做在資料庫裏的View物件, 或是在程式中做出來的View物件.
有人會說, 如果Table結構改變, 相關的View就會要全部調整, 這個是免不了的工作, 但是系統一旦開發完成, 要改變Table結構, 不是那麼常有的事. 或者, 在Table設計時, 預留一些空欄位, 以便日後需要時使用, 這樣就不會改變Table結構.
在資料庫系統中, 適當的使用View可以減少Data Duplicate的問題, 例如在Oracle的ERP系統的資料庫中, 就大量的使用View來讓前端Forms和Reports設計簡化.

會用啊,怎麼不會用??
資料庫輸入的資料是由很多地方很多使用者觀點然後進入正規化的關聯Table
比如從訂單系統,庫存系統,財務系統..不同的角色輸入不同的資料

輸出就是用View
把這些資料用不同的觀點輸出給不同的角色..
比如說董事長,總經理,顧問..不用看原始資料,他要用有用的統計數據
會計師要的財務報表..要的報表跟公司內部的財務報表也不同

另外就是SP 跟 View
我是用SP比較多,我做線上交易較多,邏輯較多所以用SP較多
如果做統計,資料採礦,歷史資料..就要用View
因為View會做索引表,會佔較多存放空間,且資料異動大時,就要維護索引表

從來不用 view 與 sp。

對 DBA 而言，因為沒有程式輔助，所以會用 view 來切分角色權限，會用 sp 來簡化日常指令工作。但是對 programmer 而言，角色權限與 function routin，我都已經在程式上切分 layer 了。資料庫就單純做資料儲存的工作，結構單純、移植容易，所有的系統邏輯都在程式上做完，工作要交接也不必在資料庫上花費太多時間，尤其是對資料庫不熟的 programmer，要他 debug 到資料庫裡面去根本是自找麻煩。programmer 只需知道 table 用途，其它全都只需動程式就 OK 了。系統要升級也不用為資料庫傷腦筋，頂多建立新 table 或新欄位，全都可以自動化。

我的程式通常是這樣的 layer：
Web / Application
↓
介面層 (負責解析 API 參數、JSON、XML、GET/POST 參數等)
↓
商業邏輯層 (負責提供實際功能 API)
↓
資料庫邏輯層 (負責提供來自資料庫的邏輯判斷。比如角色權限、常用關聯)
↓
資料庫抽象層 (負責把底層 DB 的 API 抽象化)
↓
資料庫 (MySQL、MSSQL、Oracle、...)