iT邦幫忙

0

大家有沒有使用 資料庫的VIEW?

  • 分享至 

  • xImage

大家在系統中有沒有使用 資料庫的VIEW?
若有? 為何使用?
若沒有? 為何不使用?

一樣除了贈點以外,另外準備了匈奴國與東瀛國的作品10份.

看更多先前的討論...收起先前的討論...
總裁 iT邦好手 1 級 ‧ 2013-06-21 14:34:05 檢舉
為什麼都問我不會的....抗議
另外有幫您準備 VIP版的,等嫂夫人不注意時,遞給您.
總裁 iT邦好手 1 級 ‧ 2013-06-21 14:48:13 檢舉
謝謝臉紅喜歡
外獅佬 iT邦大師 1 級 ‧ 2013-06-21 15:14:36 檢舉
有聽過如此一說:
用View,當變更資料表結構的時候,會比較麻煩,因為,連View都可能需要更動。
尤其是那種需要發佈給各點使用的系統,蓋麻煩...
外獅佬 iT邦大師 1 級 ‧ 2013-06-21 15:18:55 檢舉
hitomitanaka提到:
VIP版

那個一定要view的....臉紅
先來說說我自己吧,VIEW用的非常多.
一般程式幾乎都是連到VIEW,而不是連到Table.
至於為何這樣做呢? 就先賣個關子.
總裁 iT邦好手 1 級 ‧ 2013-06-21 16:55:50 檢舉
老闆,給我兩個關子帶走,少冰不要辣.....暈
Albert iT邦高手 1 級 ‧ 2013-06-21 20:53:15 檢舉
hitomitanaka提到:
一般程式幾乎都是連到VIEW,而不是連到Table.


我們客製化 Oracle ERP
就是把 View 拆了 抓回原來的 Table
才能速度超越 Oracle ERP 原廠 的龜速系統
要快 100倍
請要小心 Oracle ERP 的 View 是怕你錢多沒地方花
買硬體 3000萬也沒把 View 拿掉快
架空 Oracle ERP/SAP ECC 我們經驗最豐富

技術轉移顧問
Skype: ADempiere/Compiere
Albert
ted99tw iT邦高手 1 級 ‧ 2013-06-21 21:55:03 檢舉
為什麼會的都不問我...抗議
讚 感謝亞伯大師蒞臨指導
charmmih iT邦研究生 5 級 ‧ 2013-06-24 00:56:30 檢舉
albertachen提到:
就是把 View 拆了 抓回原來的 Table

在我調校過程中, 通常我會拆VIEW, 是因為外層where 篩選條件無法下到內層的基底表格(base table), 直接使用基底表格去寫SQL; 另一個解決是瞭解VIEW的邏輯後, 改寫VIEW, 讓VIEW 外層where 篩選條件可以下到內層的基底表格(base table) , 這樣仍可沿用VIEW .
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
6
賽門
iT邦超人 1 級 ‧ 2013-06-23 00:12:04
最佳解答

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

charmmih iT邦研究生 5 級 ‧ 2013-06-24 00:50:37 檢舉

iT邦幫忙MVPsimon581923提到:
適當的使用View可以減少Data Duplicate的問題,

Data Duplicate , 是來自錯誤的SQL....
透過VIEW可預先寫出正確的SQL, 讓後續使用到VIEW 的開發者不會產生Data Dulpicate的問題;
反之, VIEW 的SQL不正確或寫得不好, 會造成後續使用到VIEW產生資料錯誤或效能不好的連鎖反應.

8
pantc328
iT邦高手 1 級 ‧ 2013-06-21 15:05:26

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

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

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

charmmih iT邦研究生 5 級 ‧ 2013-06-24 00:44:49 檢舉

pantc328提到:
因為View會做索引表,會佔較多存放空間,且資料異動大時,就要維護索引表

View 只是一組虛擬的select SQL指令, 在執行時才能去抓資料; 除非是material view 才會去綁定實體資料;
除了FULL SCAN 的SQL用不到索引, 其餘皆會用到索引; 換句話說, 每一個SQL最好有其相關表格的合適索引; 尤其是資料多的表格, 若有合適的索引才會有好的效能.

12
wiseguy
iT邦超人 1 級 ‧ 2013-06-21 17:49:47

從來不用 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、...)

看更多先前的回應...收起先前的回應...
pantc328 iT邦高手 1 級 ‧ 2013-06-21 22:57:33 檢舉

你這是簡單的模型,一人包全部層

但系統大時,就要分層,分工
我只要一個地方改,全部跟著改
而且後端裡有非常多服務在跑

我都會 UI層,UI邏輯層,企業實體層,企業流程,資料存取層,服務層,資料邏輯層,資料存放層..
系統小,開發成本貴,但當系統到達某種規模,成效就差很多

pantc328 iT邦高手 1 級 ‧ 2013-06-21 23:03:15 檢舉

Web / Application /SmartDevice/WebService....

介面層 (負責解析 API 參數、JSON、XML、GET/POST 參數等),SOAP,其他通訊

商業邏輯層 (負責提供實際功能 API)

資料庫存取層 (將資料層序列反序列成程式的物件)

資料層(資料庫,檔案,WebService)

wiseguy iT邦超人 1 級 ‧ 2013-06-21 23:26:20 檢舉

pantc328提到:
你這是簡單的模型

可以達到需求就是好模型,為什麼非複雜不可?

pantc328提到:
一人包全部層

什麼叫一人包全部層?不懂。我的團隊沒有什麼一人包全部層,而是每個人都能解決各層問題,因為一點都不複雜。

pantc328提到:
我只要一個地方改,全部跟著改

我只要一個地方改,其它通通不必改。

pantc328提到:
我都會 UI層,UI邏輯層,企業實體層,企業流程,資料存取層,服務層,資料邏輯層,資料存放層...系統小,開發成本貴

只考慮到開發成本,但工作交接、部署、教育訓練、測試、維護、除錯,甚至要找個既會寫程式,又懂資料庫,還會調校系統的工程師都沒那麼容易 ... 這些通通都是成本。

外獅佬 iT邦大師 1 級 ‧ 2013-06-22 00:49:17 檢舉

wiseguy提到:
既會寫程式,又懂資料庫,還會調校系統的工程師

汗Orz爆氣

有的時候, 我會把資料庫邏輯層抽出來寫在SP
目的是為了:

  1. Programer只要呼叫SP即可, 不用理解裡面的資料存取邏輯
  2. 針對schema異動頻率高的table, 修改SP即可, 不用重新編譯程式

至於view, 有時也會用, 通常運用在關聯比較複雜的報表上.
讓report desinger在呼叫data source時的語法比較簡潔明瞭
而且效能上也會有幫助

還有一點, 我可以確保報表語法的有效率性和index搭配完整性

我要發表回答

立即登入回答