文章图片

作者介绍
黎君原 ， 新炬网络架构师 。
“贰过” ， 重犯同一过失的意思 ， 语出《论语》 ， 完整句子为“不迁怒不贰过” ， 乃仲尼对其不幸早逝的弟子颜回的极高评价 。 就it项目而言 ， 从管理者的角度来说 ， 一个错误犯两次 ， 别说是同一个人了 ， 哪怕是同一团队的不同人也不可接受 。 说到这里 ， 不由得脑补出一位平时慈眉善目的老领导作嗔怒状 ， 大喊“干掉干掉”的恐怖场面 。 不重犯同一错误真的很难吗 ， 实话实说 ， 确实难 ， 君不闻 ， 人类从历史中得到的最大教训就是从不吸取教训 。
笔者上述感叹的背后是有故事的 。 那是本世纪最“2”的一天 ， 笔者在排查Oracle到ADB（此处指ADB PG ， 全称AnalyticDB PostgreSQL版 ， 是阿里的MPP架构的数据库）之间数据实时同步过程中 ， 突然发现自己埋了个大雷——没区分空值和空字符串 ， 导致同样的字段值在全量同步阶段标志为空字符串 ， 增量同步阶段则标志为空值 ， 这显然不是一种合乎逻辑的行为 。
其实在发现这个问题前 ， 笔者已经在这项目中苦苦挣扎了一个月 ， 在此之前的两天 ， 笔者自以为数据质量已经完全没问题 ， 数据同步达到“又不是不能用”的境界了（笔者注：此处能用是真的能用 ， 非为上线而上线那种能用） 。 Oracle DB本身确实不区分空值和空字符串 ， 对于搞Oracle出身的工程师 ， 没意识到这个似乎情有可原 ， 然而笔者作为搬砖佬 ， 已经前前后后搬了十几年 ， 数据库异构迁移项目也认认真真地做过好几个 ， 这件事对笔者而言 ， 其实无异于“低级错误” 。
回想起来 ， 这个项目笔者做得甚是狼狈 ， 这里面固然有进度紧以及新工具、新技术引入需要边学边用的客观因素 ， 但这不足以平息笔者对自己的愤怒 。 问题来了 ， 在开源技术使用日益广泛的今天 ， 笔者也可能突然被要求用一个新工具同步数据到一个新数据库 ， 时间还可能更紧迫 。 到时怎么办呢？再愤怒一次吗？不了不了 ， 还是脚踏实地总结一下 ， 记下这些坑 ， 日后类似项目 ， 哪怕被拿着枪指着头也好 ， 下述问题都要在前期阶段予以考虑 。
一、空值和空字符串
对于Oracle DB?? ， 空值和空字符串是同?回事 ， 其中判断某个值是否为空值/空字符串统?使?"IS NULL"即可 ， ?于=''是?效的 。
这点对于其余数据库来说 ， 可真不?定了 。 就源端为Oracle DB ， ?标端为其余数据库的项??? ， 我们需要与开发商确认好 ， ?标端究竟?哪种值表?源端的空值/空字符 。 ?对于实时同步的项?来说 ， 还需要在全量同步以及增量同步期间保持数据的?致 。
除了空值和空字符串以外 ， 其实还有?个隐藏的?boss——固定?度类型中的空格值 。 以Oracle DB为例 ， char类型?于存放固定?度的字符串 ， ??度不?的字符串则会被?动补充空格 ， 对于这种值 ， ?论是char_col=''还是char_col is null均?法识别 ， 只能通过trim(char_col) is null识别 ， 对此值使?length函数会返回本字段的?度 ， ?个?0值 。 ?这种数据同步到adb后则表现有?定差异了 ， char_col=''可以识别这种数据（哪怕ADB中也是?了固定?度的数据类型） ， 然?对这个值使?char_length函数 ， 结果会返回0 ， 如果实在要把这种数据抓出来 ， 我们还得加?个条件oct_length(char_col)>0 。 很明显 ， 这?是?个坑！
二、数据类型转换问题
笔者的朋友阿强一直立志做一个温文儒雅的人 ， 嗯 ， 前提是不要让他“写材料”、“擦屁股”以及“估算工作量”！没错 ， “估算工作量”对他这种以txt狂魔自称的人来说是一种煎熬 ， 光说起这个词 ， 他已经脑补出把pm按在地上 ， 一边揍一边说 ， “我想做个好人 ， 为什么要逼我”？问题来了 ， 如果让阿强估算这个数据类型转换的工作量 ， 估计他连40米的刀都可以拿出来了 。