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