Re: [SQL ] 一些關於SQL Server的問題
※ 引述《jameswiki》之銘言：
: ※ 引述《flakchen (flak)》之銘言：
: : 沒錯，面對這麼大的資料量作垂直或水平分割（Partition）是基本手段
: : 也比較多，但這也使資料表規劃技巧更形重要
: flakchen大,Soga,了解了,所以像您這種資料庫,一個table上億筆,
: 根本無法用left join,
: 我想應是少數案例吧,如果是常態,每個人的DB table中都上億筆,
這種超大資料庫的設計在國外叫作VLDB（Very Large Database）
在國內感覺比較少人提，但國內客戶與程式開發人員也就因此都有刻板印象：
認為MS-SQL是沒辦法作超大資料庫的存放的
事實上，MS-SQL在效能的確與Oracle有一段落差，但在SQL2000以後其實是可以承受
VLDB的，但在設計跟程式設計上就會多出一些東西要注意
像這個網頁就在討論這個問題，不過他這裡的Tip太簡單了，比較有用的還是得到
SQL Magazine去找
http://www.sql-server-performance.com/tips/vldb_p1.aspx
: 就請微軟癈了left join指令就好了!
: (或說:資料庫的left join,full join根本不應存在,因為一用就影響效能甚距)
如果是少筆的資料表互相JOIN，當然LEFT跟FULL還是可以用的，這在算數運算上
可以簡化程式碼，不必因噎廢食
: ,作業用DB中有存放過去6個月-1年的資料,所以也不用常跨DB查詢
: 平日一個now_db就是有今日起到去年今日的資料,可供作業使用,
: 臨時一個跨過去年今日的跨年度的查詢需求,
: 也只是跑一個union來處理就OK
這種在SQL 2005上就是用Partition Table來處理，很好用，但比較複雜
不過發生的機率不大，或是查詢容忍時間比較長就算了，因為這要Ent.版才有
: 感覺您的資料,有可能比較像銀行ATM存提款的交易記錄之類的,
: 才有可能破億吧?
沒錯，的確是機器產生的記錄類資料，人工輸入的資料都是小Case，很少能累積這麼多
只是要說明，前面之所以有人會提到用Idenrity欄位作Clustered Index/PK
的原因是效能上的關係，當然這問題不是每個Case就會遇到，不過這種「老生常談」
的經驗法則通常都是因應最惡劣的情況所產生的
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 203.70.51.189
推
03/19 17:20, , 1F
03/19 17:20, 1F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 12 之 12 篇)：