27,582
社区成员
发帖
与我相关
我的任务
分享高分速度求语句--第三季
表1数据如下：
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......
表2数据如下：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
注意：以上数据 1 2 3 是有重复的，如何把 表1 更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......
表2数据如下：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
注意：以上数据 1 2 3 是有重复的，如何把 表1 更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......
...全文
请发表友善的回复…
发表回复
叶子 2011-07-07
- 打赏
- 举报
[Quote=引用 41 楼 arrow_gx 的回复:]
每天有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......
每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
……
[/Quote]
明白楼主的意思了
设计的时候是关系表的，但是现在是要做统计，但是统计的格式的字符串拼接的
但是数据量大导致效率问题
每天有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......
每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
……
[/Quote]
明白楼主的意思了
设计的时候是关系表的，但是现在是要做统计，但是统计的格式的字符串拼接的
但是数据量大导致效率问题
叶子 2011-07-07
- 打赏
- 举报
这个效率很难控制，一对多还是需要用关系表来处理
这样拼字符串+数据大是提高效率的瓶颈！
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
这种结构一般超过10000以上的数据，就强烈建议不要使用了。
还是按晴天说的那种：
1 111
2 112
3 331
3 332
3 333
这种处理好一些。
这样拼字符串+数据大是提高效率的瓶颈！
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
这种结构一般超过10000以上的数据，就强烈建议不要使用了。
还是按晴天说的那种：
1 111
2 112
3 331
3 332
3 333
这种处理好一些。
arrow_gx 2011-07-07
- 打赏
- 举报
每天有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......
每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
历史表采用 一对多 的方式进行记录，
例如当前数据：
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......
如何利用统计结果，将历史表去掉重复数据，更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......
唉，不知道这样说，够清楚了吗，大家是否看的明白 ？？？ 我语文差，大家见谅
每天一个新表里面的的记录为：
1 111
1 112
2 221
2 222
......
每天统计出一下结果：
1 112,113
2 222,223,224
3 332,333,335,336
4 441,442
5 551,552,553,554
......
历史表采用 一对多 的方式进行记录，
例如当前数据：
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
......
如何利用统计结果，将历史表去掉重复数据，更新为：
1 111,112,113
2 221,222,223,224
3 331,332,333,334,335,336
4 441,442
5 551,552,553,554
......
唉，不知道这样说，够清楚了吗，大家是否看的明白 ？？？ 我语文差，大家见谅
Mr_Nice 2011-07-07
- 打赏
- 举报
其实这个问题，LZ需要取舍的。
结构不好，后期需要很多特殊方法处理数据，比如：拆分列值，再合并之类的。
无非就是算的快慢的事儿，这些都是消耗硬件资源，如果LZ硬件够好，基本可以忽略。
结构好些，就是I/O的事儿，千万行记录，这个I/O怎么都不会省的。
结构不好，后期需要很多特殊方法处理数据，比如：拆分列值，再合并之类的。
无非就是算的快慢的事儿，这些都是消耗硬件资源，如果LZ硬件够好，基本可以忽略。
结构好些，就是I/O的事儿，千万行记录，这个I/O怎么都不会省的。
arrow_gx 2011-07-07
- 打赏
- 举报
每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
-晴天 2011-07-07
- 打赏
- 举报
还是没明白你的意思.
反正,用拼接字符串的活儿去干上千万条记录的事儿,那可千万别去做.除非你有足够足够的时间去等一个运行了一场足球赛都结束它还没完的查询语句.
反正,用拼接字符串的活儿去干上千万条记录的事儿,那可千万别去做.除非你有足够足够的时间去等一个运行了一场足球赛都结束它还没完的查询语句.
arrow_gx 2011-07-07
- 打赏
- 举报
这里 userid= 1 2 3 4 5 等，比如 userid=1 的用户，对应的记录就是 111,112
这里的 111,112 在原始记录里面是 两条记录
1 111
1 112
这样说明清楚了吗？ 唉，我语文不够好，说不清楚，见谅了啊
这里的 111,112 在原始记录里面是 两条记录
1 111
1 112
这样说明清楚了吗？ 唉，我语文不够好，说不清楚，见谅了啊
arrow_gx 2011-07-07
- 打赏
- 举报
伪命题.
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?
不是这样的，是 一个 userid 有可能对应多条记录
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
这里 userid= 1 2 3 4 5 等，比如 userid=1 的用户，对应的记录就是 111,112
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?
不是这样的，是 一个 userid 有可能对应多条记录
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
这里 userid= 1 2 3 4 5 等，比如 userid=1 的用户，对应的记录就是 111,112
-晴天 2011-07-07
- 打赏
- 举报
[Quote=引用 33 楼 arrow_gx 的回复:]
引用 32 楼 qianjin036a 的回复:
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
问题是1对1 的进行记录，有可能 一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了[/Quote]
伪命题.
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?
引用 32 楼 qianjin036a 的回复:
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
问题是1对1 的进行记录，有可能 一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了[/Quote]
伪命题.
如果一个userid对应有上千万用户,请问,按你这样的设计,第二列的数据类型是什么?
arrow_gx 2011-07-07
- 打赏
- 举报
[Quote=引用 32 楼 qianjin036a 的回复:]
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!
[/Quote]
问题是1对1 的进行记录，有可能 一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了
引用 31 楼 arrow_gx 的回复:
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!
[/Quote]
问题是1对1 的进行记录，有可能 一个 userid 会对应上万条记录，我倒不是怕硬盘空间问题，是怕后面的处理效率问题，因为后续处理是针对每一个用户进行分析的，有几百上千万用户，处理起来就很麻烦了
-晴天 2011-07-07
- 打赏
- 举报
[Quote=引用 31 楼 arrow_gx 的回复:]
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
[/Quote]
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
[/Quote]
还没想通?
如果这个表里的记录太多,也就是行太多,就不好办了?
那如果不是用行,你不是还得把这些数据插入到同一行里?
换成单一的行,会增大数据量吗?
显然木有!!!!!!
arrow_gx 2011-07-07
- 打赏
- 举报
有点没拿定主意，最后的历史表有一个应用，就是要对表里的每个 userid 进行分析，如果这个历史表记录太多，也会影响后期的处理，唉，有点难办
-晴天 2011-07-07
- 打赏
- 举报
[Quote=引用 22 楼 arrow_gx 的回复:]
量太大了，每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
[/Quote]
行变多,并不意味着数据量大.
这样的结构还有个问题,你的第二列数据长度设置是多少?你预先会知道每行会添加多少个逗号吗?如果不知道,那不是得把这列设置为nvarchar(max)了!
量太大了，每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
[/Quote]
行变多,并不意味着数据量大.
这样的结构还有个问题,你的第二列数据长度设置是多少?你预先会知道每行会添加多少个逗号吗?如果不知道,那不是得把这列设置为nvarchar(max)了!
Mr_Nice 2011-07-07
- 打赏
- 举报
[Quote=引用 22 楼 arrow_gx 的回复:]
量太大了，每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
[/Quote]
还是得根据应用来看结构，如果LZ后期需要针对每条明细查询的话，建议还是标准的
1 111
1 112
2 221
这样的结构，虽然数据行会变多，但还可以用加索引等方法来进行优化。
如果用算法来处理数据，再进行连接，无形中又添加了处理的难度和资源消耗。
亿级别数据的处理基本的思路是分库与分区
另外，明细汇总时，建议每天进行数据仓库类的处理。
这样可以从计算亿级降低到千万级别，如果可以的话，数据汇总时间可以多次，
再从千万级，降低到百万级，相信对于硬件来说，几次百万级的汇总会比一次千万级来的要容易些。
参考
量太大了，每天会有上千万条的记录，而且有很多会有重复，目前想每天一个新表，然后把结果统计到一个历史表里面，
历史表采用 一对多 的方式进行记录，
1 111,112
2 221,222,223
3 331,332,333,334
4 441,442
5 551,552,553,554
[/Quote]
还是得根据应用来看结构，如果LZ后期需要针对每条明细查询的话，建议还是标准的
1 111
1 112
2 221
这样的结构，虽然数据行会变多，但还可以用加索引等方法来进行优化。
如果用算法来处理数据，再进行连接，无形中又添加了处理的难度和资源消耗。
亿级别数据的处理基本的思路是分库与分区
另外，明细汇总时，建议每天进行数据仓库类的处理。
这样可以从计算亿级降低到千万级别，如果可以的话，数据汇总时间可以多次，
再从千万级，降低到百万级，相信对于硬件来说，几次百万级的汇总会比一次千万级来的要容易些。
参考
arrow_gx 2011-07-07
- 打赏
- 举报
其实现在我已经是这么做了。 这个问题的 表1 对应我前一个问题的 统计结果，，
问题链接如下
http://topic.csdn.net/u/20110707/09/1d247f05-d369-46da-b3cb-74da6c2eba04.html?53086
现在问题是 ，统计出来的结果，和历史结果之间，如何更新，或者说 历史表，也简单的采用 1对1 的方式，直接记录数据？ 那样初步估计也太大了...
以上这些做完以后，还要对整个历史表进行后续处理的，效率比较难解决
问题链接如下
http://topic.csdn.net/u/20110707/09/1d247f05-d369-46da-b3cb-74da6c2eba04.html?53086
现在问题是 ，统计出来的结果，和历史结果之间，如何更新，或者说 历史表，也简单的采用 1对1 的方式，直接记录数据？ 那样初步估计也太大了...
以上这些做完以后，还要对整个历史表进行后续处理的，效率比较难解决
arrow_gx 2011-07-07
- 打赏
- 举报
用一個表記錄表3 ??
表3 的结构如何 ？？
表3 的结构如何 ？？
中国风 2011-07-07
- 打赏
- 举报
[Quote=引用 24 楼 arrow_gx 的回复:]
引用 20 楼 varbinary 的回复:
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗
结构方面可以改，但改成什么样的比较合适呢 ？？
[/Quote]
表1，表2每條記錄分開，便於更新。用一個表記錄表3
引用 20 楼 varbinary 的回复:
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗
结构方面可以改，但改成什么样的比较合适呢 ？？
[/Quote]
表1，表2每條記錄分開，便於更新。用一個表記錄表3
AcHerat 2011-07-07
- 打赏
- 举报
程序里拆分后存入表应该会好点吧！就是插入的时候直接按
1 111
1 112
1 113
这样子插入，再者显示为 1 111,112,113 应该没什么用处吧！如果,有几百个几千个，页面再怎么看是看不完的。
1 111
1 112
1 113
这样子插入，再者显示为 1 111,112,113 应该没什么用处吧！如果,有几百个几千个，页面再怎么看是看不完的。
arrow_gx 2011-07-07
- 打赏
- 举报
[Quote=引用 20 楼 varbinary 的回复:]
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗
[/Quote]
结构方面可以改，但改成什么样的比较合适呢 ？？
既然这么大数据，既然知道很慢，既然知道现在的结构做起来很难
为什么不考虑修改结构呢？这不是自讨苦吃吗
[/Quote]
结构方面可以改，但改成什么样的比较合适呢 ？？
中国风 2011-07-07
- 打赏
- 举报
如果記錄的有效性周期不長，可以采用歷史庫，把舊數據庫搬動到歷史庫，需要時再調用
加载更多回复（35）
