123
返回列表 发新帖
楼主: yangxiangdong

数据库判断重复是否可取

[复制链接]
论坛徽章:
2
授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34
21#
发表于 2004-12-9 19:27 | 只看该作者

Re: 数据库判断重复是否可取

最初由 yangxiangdong 发布
[B]现在有一个表需要保存三个月的历史数据--2亿条左右,占70个G左右的空间,每天需要把文本文件入库,可能会有很多重复的记录,请问使用数据库自身判断重复可不可行,如果不这样的话有没有什么好的办法。 [/B]



我也來加一句.
我想問的是,是不是假如發現這個數據數據庫有的,這數據就不給insert進去?如果是的話,請看下面:
假設現在有2億數據。
你把這2億數據分成4個table(當然也可以3,5個)
假如是表A,B,C,D
每個表占用5000萬的數據。(具體怎麼實現我就不多講了)
這四個表都有PK,
你insert的時候,有順序的查找A->B->C->D
當查找A的時候,如果發現有重復的話就可以馬上返回了。
如果A沒有,再找B......
這樣的好處是,你每次找的數量大大的減少。如果好叩脑挘?贏表的時候就找到了,大不了就去B表,再不好也就是找到D了。

使用道具 举报

回复
论坛徽章:
1
会员2006贡献徽章
日期:2006-04-17 13:46:34
22#
 楼主| 发表于 2004-12-10 08:41 | 只看该作者

您的办法我也试过

以前作forpro的时候经常这么干,但是觉得在当前的数据库条件下也许不是最佳选择,起码如果在oracle下建垂直分区要好得多,管理起来更方便,而且比较几次的结果也未必比比较一次要快

使用道具 举报

回复
论坛徽章:
0
23#
发表于 2004-12-10 10:59 | 只看该作者
比较上肯定要消耗很多时间,就算是算法很好按照你的数据量和需求也不一定能提高多少。莫不如从insert 上提高效率,呵呵 在insert 过程中加append 不通过回滚段 应该能快不少

使用道具 举报

回复
论坛徽章:
2
授权会员
日期:2005-10-30 17:05:33会员2006贡献徽章
日期:2006-04-17 13:46:34
24#
发表于 2004-12-10 14:53 | 只看该作者
'而且比较几次的结果也未必比比较一次要快'
是未必,但是你要看機率。也許通常只是找第一個table就找到了。

使用道具 举报

回复
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
25#
发表于 2004-12-10 14:55 | 只看该作者
最初由 ssonu 发布
[B]比较上肯定要消耗很多时间,就算是算法很好按照你的数据量和需求也不一定能提高多少。莫不如从insert 上提高效率,呵呵 在insert 过程中加append 不通过回滚段 应该能快不少 [/B]


用的是sybase.
如果是oracle不如使用merge
sql> desc a
名称                                      是否为空? 类型
----------------------------------------- -------- --------------------------

SERV_ID                                            NUMBER
C1                                                 VARCHAR2(100)

sql> desc b
名称                                      是否为空? 类型
----------------------------------------- -------- --------------------------

SERV_ID                                            NUMBER
C1                                                 VARCHAR2(100)

sql> l
  1  merge into a
  2  using b
  3  on (a.serv_id = b.serv_id)
  4  when matched then
  5  update set a.c1 = a.c1
  6  when not matched then
  7* insert /*+append*/ (a.serv_id,a.c1) values(b.serv_id,b.c1)
sidb@ecx> /

500 行已合并。

使用道具 举报

回复
论坛徽章:
168
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-02-13 15:10:582012新春纪念徽章
日期:2012-01-04 11:49:54蜘蛛蛋
日期:2011-12-05 16:08:56ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41设计板块每日发贴之星
日期:2011-07-22 01:01:02ITPUB官方微博粉丝徽章
日期:2011-06-30 12:30:16管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:33
26#
发表于 2004-12-10 15:00 | 只看该作者
本质问题还是在为何产生重复数据上面,要知道,如果应用设计/做得好的话是不会有重复记录产生的.
btw:与其停留在技术问题上不如从系统设计上看看是否有所突破.

使用道具 举报

回复
论坛徽章:
1
会员2006贡献徽章
日期:2006-04-17 13:46:34
27#
 楼主| 发表于 2004-12-10 15:30 | 只看该作者

您说的没有错

如果能从应用上保证重复的问题当然是最好的,但是有时候无法避免阿,比如我们这个应用数据是通过一种设备进行采集的,有的时候这个设备出现故障了采集下来的数据发现丢了几条,那么就要全部进行重新采集(无法单条重采集),如果前面的已经上传了,那重新采集这部分就会有很大一部分是重复的

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表