比如你有个用户表，用身份证号做主键 <- 中国开发网

账号

中国开发网: 论坛: 程序员情感CBD: 贴子 835921

dead_lee · 2010-08-05 08:47:42 · 阅读: 780

比如你有个用户表，用身份证号做主键

那么别的表就是用这个值和你关联，15变18后，你要修改所有的主从表，如果是业务无关字段作为用户表的主键，15变18你就改主表好了

相关信息:

讨论2：sql/index 优化讨论 (591字) (ahfei [1072] 2010-08-05 15:03)
- 问题1，表很大的情况下，如果某field只有几种变化（类似status栏位)，加不加索引？ (空) (ahfei [528] 2010-08-05 15:04)
  - 我的意见：如果该字段要经常跟其他表关联，要索引。 (空) (疯子张 [487] 2010-08-05 15:08)
  - 不加, 根據值做表分區 (空) (dead_lee [457] 2010-08-05 15:36)
  - 加 (空) (DeepBlue [459] 2010-08-05 15:39)
  - 加 (12字) (steel1 [438] 2010-08-05 15:52)
  - 有一个栏位，值只有2种可能Y/N，加了索引后，速度更慢了 (空) (ahfei [505] 2010-08-06 15:27)
    - DDL 在内 (1429字) (ahfei [482] 2010-08-06 15:30)
- 问题2, date类型做索引，会不会慢很多？设计上要不要改成整数？ (空) (ahfei [595] 2010-08-05 15:05)
  - 搭车问DB专家一个问题：给其它表做外键的主键用字符串好还是用整数好？ (73字) (pcplayer [825] 2010-08-05 15:09)
    - 按常识，肯定是整型效率最高 (32字) (haitao [481] 2010-08-05 15:13)
    - 主鍵習慣用沒有業務含義的值,比如自增長的字段. 你這個合適加上unique的索引. (空) (dead_lee [579] 2010-08-05 15:37)
      - 主键是表达了商业逻辑，用来区分2行记录的。需要无商业逻辑的自增长字段的话就要考虑表的设计是否符合几个范式了。 (空) (DeepBlue [565] 2010-08-05 15:55)
        約束條件可以通過數據庫的約束體現,主鍵要被各種表關聯,用業務字段有風險,比如身份證,15變18 (空) (dead_lee [520] 2010-08-05 16:00)
        我也是尽量以用户看不见的内部关联id做主键，业务字段的确不保险 (73字) (haitao [653] 2010-08-05 16:05)
        最好不要用自增的ID做关联，否则数据移植时会比较麻烦，弄不好就乱套，自己写个序列生成器好了。 (空) (疯子张 [599] 2010-08-05 16:26)
        据个例子而已，现在用guid更方便 (空) (dead_lee [491] 2010-08-05 16:43)
        能否具体举例下呢? 我怎么觉得身份证15变18和他是否是主键没关系 (空) (DeepBlue [428] 2010-08-05 16:07)
        比如你有个用户表，用身份证号做主键 (64字) (dead_lee [779] 2010-08-05 16:47)
        的确，用户说不变的、唯一的东西，后来还是可能变或不唯一的。。。。。。。。 (27字) (haitao [545] 2010-08-05 17:32)
        估计你举的例子不好，分析下你举的例子 (315字) (DeepBlue [570] 2010-08-05 18:08)
        好像相反吧，不使用业务字段主关联，所有表（除了1个：用户表）都不再存储业务字段，而仅仅存储用户表的对应内部id (空) (haitao [590] 2010-08-05 18:43)
        你没看懂 (空) (DeepBlue [445] 2010-08-05 23:09)
        呃, 不是 (428字) (dead_lee [547] 2010-08-06 15:38)
    - 这种情况下字符串效率好，一般建索引的时候也是把它做个hash之类的再存储的 (113字) (DeepBlue [760] 2010-08-05 15:50)
      - 这就需要了解数据库内部机制才能解答了。我也猜数据库内部应该是对字符串做了 hash ，查询起来速度也快。但存储效率可能低一些？ (99字) (pcplayer [641] 2010-08-05 16:22)
        效率不低的，而且有一种表连接叫做Hash-Join，把2个连接的字段值在内存中建立hash表后作连接 (154字) (DeepBlue [791] 2010-08-05 16:43)
        受教！空间浪费点问题不大。影响效率就问题大了。多一个整数编号字段，查询的时候的 SQL 语句都会复杂点，查询效率也会低一些。我这样理解对不？ (空) (pcplayer [545] 2010-08-05 23:37)
        是，多了次磁盘/内存的io (空) (DeepBlue [529] 2010-08-06 09:33)
        开源的 CRM vTiger 的所有表，都是拿自增整数作为主键的。究竟这样做好不好？ (空) (pcplayer [565] 2010-08-14 10:43)
      - 受教 (空) (ahfei [402] 2010-08-05 16:36)
  - 不如用字符串表示日期。 (空) (疯子张 [488] 2010-08-05 15:09)
    - 字符串比较，会比较快吗？ (空) (ahfei [741] 2010-08-05 15:16)
    - 你的項目沒有國際化的要求可以這麼玩,雖然也很不推薦 (空) (dead_lee [438] 2010-08-05 15:53)
      - 他说的日期字符串不是英文月份那种，而是yyyymmddhhmmsszzz的一部分，一般金融行业常这么干 (空) (haitao [775] 2010-08-05 23:36)
        嗯，这么干的好处是在显示和存储的时候基本上不需要进行转换处理，完全把日期当成字符串了，也不影响查询条件输入和排序。 (空) (疯子张 [658] 2010-08-06 09:37)
        我说的国际化是考虑一下几点: (95字) (dead_lee [486] 2010-08-06 15:40)
  - 直接date好了，这些基本类型的索引怎么做比较好是数据库考虑的事情 (84字) (DeepBlue [600] 2010-08-05 15:44)
  - 不要用date型，虽然它理论上只是一个数值，我一般是做成字符串用YYYYMMDD格式，可读性很好的 (空) (steel1 [606] 2010-08-05 15:53)
    - 好啥，处理的时候转换来来去去的 (空) (dead_lee [501] 2010-08-05 16:51)
- where rownum<=3000？好像正好违反了它的用法吧？？ (85字) (haitao [500] 2010-08-05 15:16)
  - 一定要包2层的 (空) (ahfei [443] 2010-08-05 15:18)
  - 我给你贴的资料你明显没读。 (空) (Miracle [399] 2010-08-06 01:27)
    - 你看清楚它的rownum<=3000出现的层次。。。。。。。。。。 (531字) (haitao [522] 2010-08-06 04:45)
      - 好吧，我认输了。不努力了 (空) (Miracle [433] 2010-08-06 09:50)
        网络沟通太累了，那就算了吧，真正用到的时候再说吧 (39字) (haitao [471] 2010-08-06 09:55)
        你自己数数ahfei的SQL有几个select先 (空) (Miracle [517] 2010-08-06 10:01)
        3个select是没错，错（当然是我认为错）在 where rownum<=3000出现的层次，我认为它应该在再外一层，才符合昨天说的通用模式 (602字) (haitao [533] 2010-08-06 10:07)
        汗，我们还是就此打住吧。 (空) (Miracle [464] 2010-08-06 11:46)
- 这样的写法我觉得有点问题 (23字) (steel1 [431] 2010-08-05 15:54)
  - 他的很多条件是用户运行时输入的吧，view无法做到；嵌套按理说可以以筛选后的小记录集参与关联，性能也可能更高 (空) (haitao [567] 2010-08-05 16:02)
  - 写成view也是被转成现在这形式再执行的，只是视觉上好看 (空) (DeepBlue [418] 2010-08-05 16:18)
  - 中间的sql是临时产生的，这里贴的是最简单的查询 (空) (ahfei [399] 2010-08-05 16:33)
- 把表和索引的DDL贴出来 (空) (DeepBlue [469] 2010-08-05 16:00)

欢迎光临本社区，您还没有登录，不能发贴子。请在这里登录

页面内容处理时间: 0.028 - 1273256