to sjzmdslxj(求知) 对sequence来说，我只是用它来标记一条记录，我并不关心SEQUENCE的连续性，删除了一条记录不连续了，也没有什么，自己生成ID的想法我也有过，但是不严密，想你说的那样用时间的生成算法，在密集操作中就可能有问题 to KingSunSha(弱水三千): 以你说的定单系统的定单系统为例，我们现在的系统也类似，所以现在的作法是在每一个表上都加上一个CORPCODE字段来标记各地的定单，并使它作为表主键的一部分，所以在系统中的表结构(超过700个)都是双主键，相当部分是3个，4个字段做了主键，写SQL语句变成update a set field5 =2 where field1=1 and field2=2 and field3=3 and field4=4....,远不如update a set field5=2 where id=4 来得简洁，而且如果业务变了，后一种的SQL词句不变，可是前一种写法可是非改不可的。所以，我的想法是北京和上海的应用分别放在两个用户下，不管是异地数据同步还是基于两个地区的数据分析应该都是没有问题的，关于SEQUENCE用完的问题，我认为在数据库中90%以上的表的数据是相对静止的，再怎么变也不会超过，只有少数表比如7,8张表才应该予以密切关注，和改变。
如果你觉得update a set field5=2 where id=4比update a set field5 =2 where field1=1 and field2=2 and field3=3 and field4=4....,来的简洁就是采用sequence的唯一原因，那我无话可讲了可是我们要处理的是全球几十个分公司的订单，在200个数据库中实现数据交换。实在没有什么简单的办法用一个sequence来处理，事实上，我们现在用的订单表的主键多达7个字段，我觉得操作非常方便。
如果你觉得update a set field5=2 where id=4比update a set field5 =2 where field1=1 and field2=2 and field3=3 and field4=4....,来的简洁就是采用sequence的唯一原因，那我无话可讲了可是我们要处理的是全球几十个分公司的订单，在200个数据库中实现数据交换。实在没有什么简单的办法用一个sequence来处理，事实上，我们现在用的订单表的主键多达7个字段，我觉得操作非常方便。
to KingSunSha(弱水三千) : "来的简洁就是采用sequence的唯一原因，那我无话可讲了",我的意思不是这个，呵呵，我的意思是用SEQUENCE作主键，业务字段做UNIQUE处理，这样它对应付可变需求要好得多，也没有什么副作用。以定单为例，这种时候我觉得应该加上一个国家名做定单联合主键的一部分的话，那：在B种设计下，参照了定单表的所有的表的应用(如发票，发货)，数据库结构肯定要改变，凡是以最终生成update语句更新数据的前台应用都要改，不仅是定单表的前台数据修改，还包括了参照了定单表的前台应用。而A种设计，就没有这种不利的地方。
第二种情况我觉得也没有什么不好的,SEQUENCE的字段主建更多的是面向数据库逻辑,而没有太多的实际物理意义,如果要反对那么多数就是这个原因了吧.
至于说是低级,我没有看出来.
打个比方，订单系统中，从上海客户数据库中发过来的一条订单号码可能和北京的订单一样，光用一个流水号怎么区别啊？
打个比方，订单系统中，从上海客户数据库中发过来的一条订单号码可能和北京的订单一样，光用一个流水号怎么区别啊？
如果业务主健很多，需要用id号来作为主键，其它的列（部分）不允许为空，这样其它表如果引用此表的主键时只关联一个id号，当然id 号类似于序列(sequence)
你可以根据需要自己做一个通用的获取id的函数,如GetId(),可以设置id的规则
年月日时分秒（记录号）200202020001；
不是所有表的主键都需要用ID 号来做主键，具体情况需要在使用中体会，sequence有其好的一面，但是往往有些数据在删除时却不能重用了，因为它不因为你删除了一条记录而自动减一。
对sequence来说，我只是用它来标记一条记录，我并不关心SEQUENCE的连续性，删除了一条记录不连续了，也没有什么，自己生成ID的想法我也有过，但是不严密，想你说的那样用时间的生成算法，在密集操作中就可能有问题
to KingSunSha(弱水三千):
以你说的定单系统的定单系统为例，我们现在的系统也类似，所以现在的作法是在每一个表上都加上一个CORPCODE字段来标记各地的定单，并使它作为表主键的一部分，所以在系统中的表结构(超过700个)都是双主键，相当部分是3个，4个字段做了主键，写SQL语句变成update a set field5 =2 where field1=1 and field2=2 and field3=3 and field4=4....,远不如update a set field5=2 where id=4 来得简洁，而且如果业务变了，后一种的SQL词句不变，可是前一种写法可是非改不可的。所以，我的想法是北京和上海的应用分别放在两个用户下，不管是异地数据同步还是基于两个地区的数据分析应该都是没有问题的，关于SEQUENCE用完的问题，我认为在数据库中90%以上的表的数据是相对静止的，再怎么变也不会超过，只有少数表比如7,8张表才应该予以密切关注，和改变。
B：用业务主键作主键，不行了，再用SEQUENCE
我的观点是A比B 好。
"来的简洁就是采用sequence的唯一原因，那我无话可讲了",我的意思不是这个，呵呵，我的意思是用SEQUENCE作主键，业务字段做UNIQUE处理，这样它对应付可变需求要好得多，也没有什么副作用。以定单为例，这种时候我觉得应该加上一个国家名做定单联合主键的一部分的话，那：在B种设计下，参照了定单表的所有的表的应用(如发票，发货)，数据库结构肯定要改变，凡是以最终生成update语句更新数据的前台应用都要改，不仅是定单表的前台数据修改，还包括了参照了定单表的前台应用。而A种设计，就没有这种不利的地方。