※ 引述《jameswiki (烏龜(弄論文中..))》之銘言： : ※ 引述《Adonisy (票投2號)》之銘言： : : 我是不懂,要猜 PK要幹嘛? : : 前端又不能自己拚 sql 指令連 sql : : 再者,我實務上也沒有用過超過10 bytes的資料型別當 pk : : 　　尤其是 clustered index　，　畢竟 clustered index的循序性很重要 : : 　　　36 bytes當 pk的話，我可能會氣死吧 : 用過了,36 bits當PK,舉二個例子,也許你的案子比我還大,所以干擾到 : clustered index效能吧? : 1.第一種case:在800多個table下,平日約500人使用沒問題,大部分是AP程式搭配 : 少部分asp+ asp.net,某特定時段,系統會有1500-2000個使用者, : 使用期至今5年以上..沒問題 重點不是有幾個Table，而是一個Table有幾筆 像我處理的資料表，動輒上千萬乃至於上億筆的，裡面半個字串欄位都不能有 更不用說拿36bytes的字串來當PK，因為它不但佔的硬碟空間多，INDEX也大 則記憶體能Cache的Index少，硬碟I/O就多，查詢速度就很慢 如果同時間能有1500-2000名使用者使用，那資料放在硬碟中應該是撐不住的 應該大部分的Index都已經載入記憶體，這也表示，總資料量其實不大，所以 可以容許用這麼長欄位跟ndex。但如果資料是幾千萬起跳的，那就必須要節省 記憶體空間，否則查詢速度可能是 幾分鐘VS 幾小時 的差別 : 3.有的公司老闆很討厭MIS自己去後台撈資料看薪資,所以有時案子是老闆 : 特別交待,要讓MIS人員撈不到資料,windows驗證故然可設權限,但是如果公司 : 全加入網域, 網域管理者一樣有權限撈資料,一樣是MIS, 設計的原則就要變成 : MIS可撈的資料,不用二進位寫入,不給MIS看的資料,改用二進位+編碼寫入,如果 : 老闆不想讓MIS自己在後台關聯table,當然就得考慮一下這些事情。甚至還得 : 加上一些東東，誰去後台撈了什麼資料，下了什麼指令，全要用SQL : mail寄給老闆。。 就正規作法而言，這應該是靠使用者權限來解決，不然那些機制也白作了 當然要故意編碼來保持機密性也不是不行，只是大部分客戶應該比較重視的 是架構的可閱讀性以及維護性 : SO..每個案子屬性不同啦,或許你的案子比較著重clustered index 吧~ 就Index資料減量的精神，Clustered Index與Primary Key除非必要 否則應該合併成同一個以減少空間耗用。而Identity欄位的確是同時滿足 這兩種Index的要求，同時又將資料耗用減輕到最少的一種資料 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.136.108.241