Re: [SQL ] 一些關於SQL Server的問題
※ 引述《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
討論串 (同標題文章)