Re: [SQL ] 一些關於SQL Server的問題
※ 引述《flakchen (flak)》之銘言：
: ※ 引述《jameswiki》之銘言：
: : <前面吃光光了..太長了XD>
: : (不要跟我說所有欄位都在同一table,你從來不用left join,那又要討論資料庫規劃
: : -->離題了XD)
: 沒錯，面對這麼大的資料量作垂直或水平分割（Partition）是基本手段
: 也比較多，但這也使資料表規劃技巧更形重要
: : 我引述下面網址的文章
: : http://blog.miniasp.com/post/2008/01/08/The-Gospel-of-the-GUID.aspx
flakchen大,Soga,了解了,所以像您這種資料庫,一個table上億筆,
根本無法用left join,
我想應是少數案例吧,如果是常態,每個人的DB table中都上億筆,
就請微軟癈了left join指令就好了!
(或說:資料庫的left join,full join根本不應存在,因為一用就影響效能甚距)
因此,您資料庫的狀況,的確是PK鍵值愈小愈好,別用太長位元~,
話說回來,PK鍵到底要用guid型態還是int型態,最終還是取決於資料庫的規模,
若像您這種上億筆, 必需要斤斤計較一點點小效能,東省西省
以提升系統效能來說,的確不合用guid型態,不然鐵定掛了
mobile SQL行動裝置受限於資源,應也不適合用Guid..XD
但一般開發DB,用guid型態來做.一個table資料量不到百萬筆,
只是拿掉一點點效能的影響,使用Guid還是有點好處的:P
看來是各有好壞了..就看資料庫規模來決定適不適合,
小弟在規劃一年有超過百萬筆可能的Table時,就會先割了,
類似這種狀況,由程式以每年的啟始,自動去產生新的Table,
以年份分開來儲存,EX: 96_db ->96年, 97_db ->97年(這些都是history Db)
作業用DB則叫 now_db (舉例..),now_db上保留前6個月-1年的資料
超過時間的..就搬到96_DB,97_Db的歷史table中
但是小弟所遇到這類型的table,大都是放歷史資料,
只是存檔,很少會有跨年度查詢的需求,所以分開放是OK的
,作業用DB中有存放過去6個月-1年的資料,所以也不用常跨DB查詢
平日一個now_db就是有今日起到去年今日的資料,可供作業使用,
臨時一個跨過去年今日的跨年度的查詢需求,
也只是跑一個union來處理就OK
有人DB用了10年,單一TABLE資料量也不會超過500萬筆,
搞不好用了不到10年,又要升級新版的DB系統了..
屆時又有更好的硬體,更好的軟體支援..
但像您這種case,一個table就上億筆,最多只能做inner join,
軟硬體再進步個5年,對您的效能加分還有限,
也就只能放棄Guid當PK鍵了!
希望F大您的table不是放BOM表資料,不然展料時,
1億筆資料真會讓人哭出來的...:P
感覺您的資料,有可能比較像銀行ATM存提款的交易記錄之類的,
才有可能破億吧?
※ 編輯: jameswiki 來自: 220.142.205.153 (03/19 12:17)
討論串 (同標題文章)