※ 引述《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