|zyciis| 在数据库中表设置是不是要去掉自增的ID呢,有时很麻烦,第二贴 大家来讨论

Question

原贴:
http://topic.csdn.net/u/20090508/11/76c72cbe-184c-4090-9706-b7f21d887eb1.html?1239816233
|zyciis| 在数据库设计的时候,当有一个字段代码为商品代码的时候,还有必要添加ID字段吗,谢谢 急
-------------------------
我自己想到自增的话数据量大时很麻烦
还有就是,本来数据库是分放各个店铺用的,现在又要合成来比如有
A店
OrderMaster
ID  Price
1   1000
OrderDetail
ID   MID   Price
1    1     1000
然后再有B店
OrderMaster (ID单主键)
ID  Price
1   1000
OrderDetail (ID单主键)
ID   MID   Price
1    1     1000
------------------------
现在如果后期有需求对他们进行合并数据的时候很麻烦
如果不是用处增的比如用
OrderMaster
BillNO            Price
OS2000905080001   1000
OrderDetail
BillNO           Sq(序号)  Price
OS2000905080001  1        1000
---------------------------------
这样设计的时候我感觉会优到前面的ID自增的设计
因为不管后期对表和数据库有什么操作的话都可以比较灵活
比如,A库和B店要求合并或程序进行升级的话,我们只要对数据库行更订单号的样式或添加字段如
OS2000905080001 => OS0A2000905080001    (0A为店铺代号)
或者
OrderMaster
ShopCode BillNO            Price
0A       OS2000905080001   1000
这样感觉对数据的改动都会比较好大家分析分析
因为我想以后建表的时候一般都不想用自增的ID来作主键
感觉不是很好谢谢

Answer 1

前期：自增键具有高效性、简洁性、安全性(高并发时保证唯一、不可更改)、可靠性等优势，
如果用自定义主键，需要许多额外的工作来弥补这些缺陷，而且效率永远也比不上自增键。
否则，你可以去sql开发团队了。 自增键不管作为连接条件、查询条件，还是用作排序、分页时，都无疑是最优之选。(极少数特殊场合除外)
后期：LZ所说的合并数据时遭遇的困难，无法苟同。
合并数据时，GUID才显现出它的优势，而自定义主键相对于自增键而言，没有任何优势。
自定义主键可以采取的解决方案，自增键同样可以采取。
例如：
合并后的OrderMaster ：
ShopCode BillNO            Price 
0A      1       1000
0A      2       1500
OB      1       2000 可以用(ShopCode,BillNo)做联合主键。甚至可以启用一个新的自增键。
以上仅供参考

Answer 2

晕,把我搞晕了
到低要不要用自增了A:用 自增键具有高效性、简洁性、安全性(高并发时保证唯一、不可更改)、可靠性等优势，
B:不用 因为我的Code已经可以作为主建了.BillNo如WS200905090001也应该可以作为主键了 再用自增的ID就多余了....