看我做的数据库包装器

IT渔夫

我靠，这个是ITPUB最长贴吗？翻都翻不完 当年讨论这个帖子的各位长老都还在这混吗？不知道楼主说的那工具使用得怎么样了

newkid

IT渔夫 发表于 2016-9-17 15:30
我靠，这个是ITPUB最长贴吗？翻都翻不完 当年讨论这个帖子的各位长老都还在这混吗？不知道楼主说的那工具使 ...

楼主偶尔还会来这里逛一下，据我所知他那个工具至今只有自己的单位在使用。

〇〇

newkid 发表于 2016-9-17 20:34
楼主偶尔还会来这里逛一下，据我所知他那个工具至今只有自己的单位在使用。

有人用的就是好工具

regonly1

我看了10多页，太长了，实在看不下去了。。。

wyq21973

newkid 发表于 2010-3-5 23:01
你这个修改源数据的做法是很不好的，不但增加了数据库负担，而且使得判断增量时不得不做全表扫描。

...

昨天才看到TOM这段关于时间戳漏洞的描述（十多年前阅读第一版时没有这个），开始以为理解了认为后续增量抽取也可能有问题，上午还发了一个关于这个的朋友圈，下午继续思考又发现不对，如果读取开始时间没有洞的话是不可能丢数据的，重看那段描述有这个疑问，为什么9:00开始第一次读所有数据（select * from table）会读不到事务在8:59:30提交所更改的数据呢？
我觉得可能说法（或者翻译）有误，那个9:00是指读完数据记下的时刻，这样就能解释通了，只要读开始时间比8:59:30早，就会读不到那个。
下次取数的开始时间以上次取数的开始时间为准，而不是结束时间，就不会有问题，大家觉得如何?

过了十年左右再来pub上发贴，有点感慨，我还在技术岗位上前行。

newkid

wyq21973 发表于 2017-1-15 18:10
昨天才看到TOM这段关于时间戳漏洞的描述（十多年前阅读第一版时没有这个），开始以为理解了认为后续增量 ...

我看了中文版的那一节，没有问题，8:59:30是修改数据的时间，不是提交时间。这个事务在9:00的时候还没有提交。

wyq21973

newkid 发表于 2017-1-16 10:50
我看了中文版的那一节，没有问题，8:59:30是修改数据的时间，不是提交时间。这个事务在9:00的时候还没有 ...

是的，前天在公司咨询了数据库专家，人家翻了一阵书也看出这个要点。