※ 引述《Adonisy (票投2號)》之銘言： : ※ 引述《jameswiki (烏龜(弄論文中..))》之銘言： : : 建議歸建議,早晚要妥協於實務,:P 如果你要寫網頁資料庫,又用數字當PK : : 要猜出你的PK值並不難..XD, 而且Uni欄位固定36 bytes,以大型資料庫來說, : : 我用36 bytes當PK識別,還是OK的..重點是,當有了這些36位元的PK,FK, : : 加上欄位都是用X001,X002,X003...即使SQL的sa帳號被人crack進去,下 : 我是不懂,要猜 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年以上..沒問題 2.第二個case,約30個Table,15000多人使用,asp.net,使用期約1個月就拿掉, 屬於公司招考的網站,後台只有AP搭配讀卡機程式,其他全用asp.net,也沒 問題 3.有的公司老闆很討厭MIS自己去後台撈資料看薪資,所以有時案子是老闆 特別交待,要讓MIS人員撈不到資料,windows驗證故然可設權限,但是如果公司 全加入網域, 網域管理者一樣有權限撈資料,一樣是MIS, 設計的原則就要變成 MIS可撈的資料,不用二進位寫入,不給MIS看的資料,改用二進位+編碼寫入,如果 老闆不想讓MIS自己在後台關聯table,當然就得考慮一下這些事情。甚至還得 加上一些東東，誰去後台撈了什麼資料，下了什麼指令，全要用SQL mail寄給老闆。。 SO..每個案子屬性不同啦,或許你的案子比較著重clustered index 吧~ --

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