110,525
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
小菩提的尾巴 2011-05-13
- 打赏
- 举报
学习了、、、
dotNetDR_ 2009-03-11
- 打赏
- 举报
数据迁移时，问题非常大。
这问题能解决
把自增消除掉然后
一条UPDATE语句
一条INSERT INTO SELECT就OK
ClassTableA
ClassID ClassName
1 初一1班
2 初一2班
3 初一3班
ClassTableB
ClassID ClassName
1 初一4班
2 初一5班
3 初一6班
----------------------
UPDATE后
ClassTableB
ClassID ClassName
4 初一4班
5 初一5班
6 初一6班
----------------------
INSERT INTO SELECT后
ClassTable
ClassID ClassName
1 初一1班
2 初一2班
3 初一3班
4 初一4班
5 初一5班
6 初一6班
这问题能解决
把自增消除掉然后
一条UPDATE语句
一条INSERT INTO SELECT就OK
ClassTableA
ClassID ClassName
1 初一1班
2 初一2班
3 初一3班
ClassTableB
ClassID ClassName
1 初一4班
2 初一5班
3 初一6班
----------------------
UPDATE后
ClassTableB
ClassID ClassName
4 初一4班
5 初一5班
6 初一6班
----------------------
INSERT INTO SELECT后
ClassTable
ClassID ClassName
1 初一1班
2 初一2班
3 初一3班
4 初一4班
5 初一5班
6 初一6班
metaphy 2009-03-11
- 打赏
- 举报
ding
chappell1 2009-03-11
- 打赏
- 举报
顶
liyangfd 2008-05-28
- 打赏
- 举报
省份证号的问题
13亿
删除添加删除添加
13亿
删除添加删除添加
qcrsoft 2008-05-27
- 打赏
- 举报
[Quote=引用 37 楼 fly4free 的回复:]
系统设计的范畴？
按你的思路，那也无从谈起“弊端”。因为“弊端”是在系统最后运行起来后才发现的
（至于设计之前就知道，那是因为有了前人在多次“系统最后运行”多次后的经验总结）
设计是为了运行，所以设计阶段是要“根据经验来考虑各种极端情况”,如：溢出怎么办？我想显示ID，用N位宽高位不足用0补，怎么办？……
设计脱离不了需求。
这类问题在楼上们的回答中有些都给出具体不足的情况了，还要怎么具体？…
[/Quote]
抛开你的上贴和我的上贴互相不理解的部分不谈了，举个例子总可以吧
系统设计的范畴？
按你的思路，那也无从谈起“弊端”。因为“弊端”是在系统最后运行起来后才发现的
（至于设计之前就知道，那是因为有了前人在多次“系统最后运行”多次后的经验总结）
设计是为了运行，所以设计阶段是要“根据经验来考虑各种极端情况”,如：溢出怎么办？我想显示ID，用N位宽高位不足用0补，怎么办？……
设计脱离不了需求。
这类问题在楼上们的回答中有些都给出具体不足的情况了，还要怎么具体？…
[/Quote]
抛开你的上贴和我的上贴互相不理解的部分不谈了，举个例子总可以吧
red_fish 2008-05-27
- 打赏
- 举报
感觉要看用在什么地方，根据需要而来.比如象一些商业应用中的记录消费流水等这种表里应用非常好。
jdlsfl 2008-05-27
- 打赏
- 举报
自增主键最大的弊端是你不知道插入的是那条记录，比较难以得到关键字
Mars.xj 2008-05-27
- 打赏
- 举报
挺好不错,各有千秋.
超级大笨狼 2008-05-27
- 打赏
- 举报
未见弊端
zhiang75 2008-05-27
- 打赏
- 举报
[Quote=引用 47 楼 cacar2008 的回复:]
缺点:
数据集成,
数据导入,
大系统分布系统并发;
问题的核心在于:作为业务逻辑的主键和记录并发\唯一性放在一个字段了,应该解耦.
[/Quote]
支持一个..问题的关键阿..
缺点:
数据集成,
数据导入,
大系统分布系统并发;
问题的核心在于:作为业务逻辑的主键和记录并发\唯一性放在一个字段了,应该解耦.
[/Quote]
支持一个..问题的关键阿..
cacar2008 2008-05-27
- 打赏
- 举报
缺点:
数据集成,
数据导入,
大系统分布系统并发;
问题的核心在于:作为业务逻辑的主键和记录并发\唯一性放在一个字段了,应该解耦.
数据集成,
数据导入,
大系统分布系统并发;
问题的核心在于:作为业务逻辑的主键和记录并发\唯一性放在一个字段了,应该解耦.
zhiang75 2008-05-27
- 打赏
- 举报
自增主键...缺点
1.在插入数据时无法确定主键的值,除非使用事务否则,通过其它方法获得,无法保证获得的值就是刚插入数据的主键,因为在插入数据库前无法获得主键导致后续代码编写困难.
2.自增值在使用事务回滚,以及在插入失败的情况下,其值不会回滚,当使用此值作为条目的连续编号时回发生编号不连续的问题.
3.在合并数据库表时,因为都是从1开始编号造成数据合并困难,特别对于一些可以离线的操作的系统,自动编号只是累赘..
因以上几点我的数据库的主键已全部改为GUID.
1.在插入数据时无法确定主键的值,除非使用事务否则,通过其它方法获得,无法保证获得的值就是刚插入数据的主键,因为在插入数据库前无法获得主键导致后续代码编写困难.
2.自增值在使用事务回滚,以及在插入失败的情况下,其值不会回滚,当使用此值作为条目的连续编号时回发生编号不连续的问题.
3.在合并数据库表时,因为都是从1开始编号造成数据合并困难,特别对于一些可以离线的操作的系统,自动编号只是累赘..
因以上几点我的数据库的主键已全部改为GUID.
gxj760998 2008-05-27
- 打赏
- 举报
主键一个很重要的作用是标志唯一，用了ID自增长，你就不用在程序中考虑这样的问题！反之，你需要用代码来管理。
这个是一个好处，至于坏处也有，看你怎么平衡啦！
这个是一个好处，至于坏处也有，看你怎么平衡啦！
xiaoqhuang 2008-05-26
- 打赏
- 举报
个人感觉,用自增ID是为了方便设主键,以满足第二范式的要求.插入记录也方便. 而且int型做为索引速度也快. id跟翻页没有关系.
如果你表有一个int型可做主键,没完没有必要用自增ID.
如果你表有一个int型可做主键,没完没有必要用自增ID.
Tll_W 2008-05-26
- 打赏
- 举报
[Quote=引用 1 楼 kzc_ljl 的回复:]
我个人觉得缺少弹性
当你有 1-10个ID 你删除了9个 只剩下1 再添加一次就是 11 而不是2
或者你有1-10个ID 你删除了8个 只剩下1和10 当你的最大ID仅仅到10的时候，你可以用一些算法来调整插入空缺ID
自增主键都是做不到的
时间越长ID变多，这些隐藏的问题暴露出来后，将变得越难以控制
[/Quote]
怕的是以后大到超出你的想象的时候就出问题了
我个人觉得缺少弹性
当你有 1-10个ID 你删除了9个 只剩下1 再添加一次就是 11 而不是2
或者你有1-10个ID 你删除了8个 只剩下1和10 当你的最大ID仅仅到10的时候，你可以用一些算法来调整插入空缺ID
自增主键都是做不到的
时间越长ID变多，这些隐藏的问题暴露出来后，将变得越难以控制
[/Quote]
怕的是以后大到超出你的想象的时候就出问题了
qcrsoft 2008-05-26
- 打赏
- 举报
楼上的楼上:
按我的猜想，让ID连续是为了类似翻页的便利是吗？如果是，这等于是无序的排列，在实际应用中几乎找不到没有一定序列的列表。或者我没理解你的意思
按我的猜想，让ID连续是为了类似翻页的便利是吗？如果是，这等于是无序的排列，在实际应用中几乎找不到没有一定序列的列表。或者我没理解你的意思
kbryant 2008-05-26
- 打赏
- 举报
:)
kzc_ljl 2008-05-26
- 打赏
- 举报
我个人觉得缺少弹性
当你有 1-10个ID 你删除了9个 只剩下1 再添加一次就是 11 而不是2
或者你有1-10个ID 你删除了8个 只剩下1和10 当你的最大ID仅仅到10的时候，你可以用一些算法来调整插入空缺ID
自增主键都是做不到的
时间越长ID变多，这些隐藏的问题暴露出来后，将变得越难以控制
当你有 1-10个ID 你删除了9个 只剩下1 再添加一次就是 11 而不是2
或者你有1-10个ID 你删除了8个 只剩下1和10 当你的最大ID仅仅到10的时候，你可以用一些算法来调整插入空缺ID
自增主键都是做不到的
时间越长ID变多，这些隐藏的问题暴露出来后，将变得越难以控制
liujunhappy2005 2008-05-26
- 打赏
- 举报
又详细看了上面兄弟们的意见，对数据迁移讨论的比较激烈。关于这个问题，我也阐述下自己的看法，有兄弟说自增一主建不连续，不适合迁移，这是对自增一主建的偏见。
还拿上面的订单为例，从客观实际出发，数据迁移，侧重点在于把编号为002的订单数据及其子数据(订单明细表中相对应的数据)，从一个数据库移到另一数据库，而不在乎编号为002的订单在2个数据库中的具体位置；如果将数据迁移做成，在原数据库第一或第二甚至第三位置的002号订单，移动到新数据库中相应的第一或第二甚至第三位置，那这不是数据迁移，叫数据库拷贝，机械的复制，是个太理想话方式，不符合实际情况，因为就算你原系统写的非常完美，绝对不出错，能保证的主建值(即订单编号)和在原数据库的位置相同，你也保证不了操作人误操作、计算机硬件系统出错等不可预知的错误，而导致主建值和在数据库中位置不一致，就别提世界上就没有100％完美的软件系统，所以将注意力集中在记录在数据库中的位置，这是一个非常不好的数据迁移方案.
还拿上面的订单为例，从客观实际出发，数据迁移，侧重点在于把编号为002的订单数据及其子数据(订单明细表中相对应的数据)，从一个数据库移到另一数据库，而不在乎编号为002的订单在2个数据库中的具体位置；如果将数据迁移做成，在原数据库第一或第二甚至第三位置的002号订单，移动到新数据库中相应的第一或第二甚至第三位置，那这不是数据迁移，叫数据库拷贝，机械的复制，是个太理想话方式，不符合实际情况，因为就算你原系统写的非常完美，绝对不出错，能保证的主建值(即订单编号)和在原数据库的位置相同，你也保证不了操作人误操作、计算机硬件系统出错等不可预知的错误，而导致主建值和在数据库中位置不一致，就别提世界上就没有100％完美的软件系统，所以将注意力集中在记录在数据库中的位置，这是一个非常不好的数据迁移方案.
加载更多回复（33）
