|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-03-12
另外，允许我离题一下，发现论坛里面有很多A V.S B的讨论到最后都有一个模式：
某个老大出来总结说：A有A的好处，B有B的好处，大家需要看情况，灵活应用，然后就是结帖。Just kidding, 
不过这个论坛讨论的气氛很好，很喜欢这里，学到了很多东西，这个周末我会去听讲座，希望可以面对面的交流学到更多的东西。 |
| 返回顶楼 | |
|
发表时间：2004-03-12
Quake Wang
potian说的公安的例子是实际发生过的，而且不是只在一个地方发生过。 在实际的企业中ProductID的命名经常是没有什么规则，而且还有可能会因为某种商业因素改变。比如今天你的产品a就叫“大老虎”，明天还是这个产品就可能叫“宝贝虎”。特别是国内的企业，你很难依靠他们提供的那些找到他们真正的命名准则。 关于身份证的那个东西我是把新和旧的都做在一个表中，我想至少最近20年你都必须这样做。 很多东西我们单纯谈技术都很合理，但是实际中完全不是一回事。我见过有人把身份证号码用数字表示，当然这个没有任何错误，可是实际中你如果这样就会很麻烦，还是当字符串的好。 |
| 返回顶楼 | |
|
发表时间：2004-03-12
呵呵，楼上citysir很可爱，
引用 我并不是说业务主键不会变，业务主键可以随时变； 我只是保证在一个表中业务主键永远不会重复就行了； 而发生关联的只有逻辑主键。有什么不妥吗？？？ ，一个表中难道还有两个非簇式的主键么？？呵呵，你的那个叫唯一约束（加上索引，就式唯一索引），这真是我们所提倡的。逻辑主键的作用只是关联引用，没有任何别的作用，而在表内的唯一性是通过业务唯一性（建立唯一约束）来保证的。
至于Quake Wang兄，呵呵，拜托，你可以看看我前面的帖子吧。我是提倡业务数据采用逻辑主键，基础数据可以根据实际情况采用业务主键的（这里所谓的业务主键并不是业务数据，而是所称的比如国家，货币，城市代码等等之类）。 我从来不是那种走极端的，因为如果一味全部用逻辑主键，在处理复杂业务的时候，就真的很麻烦了，因为一张业务表往往关联更多的基础表。但是，在业务表里也用所谓的业务主键，那就更差了（基础的东西往往很少改，即算要改，都是有比较长的时间量，并且都是为大家所共知的；而业务的东西，是每一个做软件的最薄弱的，并且是最有可能受到客户影响的，也会是最会引起问题的）。 好了，我觉得这样的问题，真是没有太多的讨论了。相信每一个稍微有些项目经验的人都会给出正确的答案，这种问题毕竟不像具体的小技术。 |
| 返回顶楼 | |
|
发表时间：2004-03-12
o，我搞错了
|
| 返回顶楼 | |
|
发表时间：2004-03-13
呵呵,这个帖子还搞了这么久啊.
|
| 返回顶楼 | |
|
发表时间：2004-10-24
robbin 写道 itpub上面那两个帖子我看过了，准确的说，他们是在讨论当使用sequence做为主键的时候，会遇到哪些问题，以及该怎么解决。虽然由此引申出逻辑主键和业务主键的取舍问题，但显然讨论不充分，因为你不能够通过否定sequence来否定逻辑主键。
业务主键的缺点我前面已经说过了，不重复提了。sequence做主键其实并不是一个好的选择，在Java的世界里真正推荐的是采用uuid，当然你也可以通过sequence来生成自己定制的uuid。当你采用uuid的时候，itpub里面针对sequence提到的4个问题，前3个问题根本就不存在了，至于第4点原文的观点是错误的，原因参考我前面的帖子。 最后要说明的是，即使采用sequence做主键，在进行数据迁移和合并的时候，也没有任何理由直接进行行记录的导入。例如如下的做法： insert into main_table select * from sub_table; 你怎么能够保证分公司的数据表里面不存在对于总公司来说是非法的数据呢？即使你用业务主键，你难道就完全能够避免主键重复的问题？对于此类问题，数据的迁移必须先经过一到validate，才能导入。而在你做validate的时候，你就应该过滤掉主键，采用总公司数据库的sequence。 对于这个，我不赞同。 主键应该尽可能的短。因为在表之间进行关联的时候，需要用到主键的索引，主键长了，会影响查询的效率，特别是在Join的表层数较多的情况下，主键长了，性能会下降一数量级甚至更多。 可能你认为UUID的比较，只要比较前几位，一般就会不同，所以不会影响比较的效率。但是，实际上不是这样的。查询时最大的开销不是比较，而是磁盘I/O的开销。主键长了，索引快一定会变大。所以，带来的开销，也会与主键的长度成正相关。 所以，我认为，在可能的情况下，应该尽可能采用短的主键，尤其是数字主键。 能用int16,就不用int32。能用byte,就不用int16。 |
| 返回顶楼 | |
|
发表时间：2005-04-06
1.采用逻辑主键
2.在业务主键上建唯一约束.如果以后该主键变化只需要把唯一约束disable即可. |
| 返回顶楼 | |
|
发表时间：2005-09-01
支持业务主键
发现很多楼上对级联更新的认识是手工操作 一些数据库提供了数据库层的自动处理支持，这个工作不用写代码来做的 不过，用业务主键的时候，有时会用中文来做主键，各位见多识广的人们认为这会不会带来一些摸名奇妙的问题 |
| 返回顶楼 | |
|
发表时间：2005-09-05
我觉得举个实际的例子更容易讨论，例如一个银行的流水表，基本信息会记录
机构号，操作员号，账户号 分别对应到机构表，操作员表，账户表，如果这三张表都是用所谓逻辑主键的话，对流水的查询就要联合4张表，尤其流水表和账户表都是超级大表，我不知道这样作有什么意义。 其实我去年的一个项目就是这样作的，当时是因为需求中明确提出上线后会有一次数据移植，这些信息都会重新编号，所以设计时这些表都加入一个保持不变的内部号。最后发现开发时工作量剧增，许多程序都要增加内外转换的逻辑。我觉得是得不偿失，还不如写一个完善一点的数据移植程序。 |
| 返回顶楼 | |
|
发表时间：2005-10-13
看过某大型国有银行核心业务系统的部分表设计，没有看到任何所谓的逻辑主键。
我认为，orm中的逻辑主键对于orm本身来说其实可以看作业务主键。 业务主键发生变更时进行一次性升级并不是多么可怕的事。相反，增加额外的逻辑主键带来的负面影响却是在时时刻刻（开发、运行、维护）的发生着。 |
| 返回顶楼 | |
