花了几个小搞定一条错误SQL带来的思考

项目背景

某标杆项目使用的国产数据库，该数据库市场推广处于起步阶段，周边工具正在不断完善，为了提高服务质量，把一下第三方dba的活给揽过来干了。今天就遇到一条SQL语句花了几个小时才搞定，处理过程中许多思考，一并记录在此。

错误排查思路

今天小姐姐告诉我一条SQL语句在测试环境查询报错，在开发环境查询正常，一时找不到原因，请我们帮忙解决一下，当时都没有询问什么情况就答应了（沟通问题）
SQL语句是长成这样的
select * from v_view where aaaa=‘44444b2322424242’;

视图里面的SQL是这样的
create or replace view as (
select * from a, b ,c where a.id=b.id and a.tid=c.dd
union all
select * from c, d ,e where c.id=d.id and c.tid=e.dd
)

排查思路
1、确认开发、测试表结构、数据类型一致 （半个多小过了，小姐姐第一次问情况，回答道正在排查）
2、aaaa字段在所有表中的数据类型一致，varchar2(20)，这里就中奖了，跨schema套了3层视图和一层同义词在找完aaaa字段类型。
就这样1个多小时过去了，小姐姐第二次问情况，回答道正在排查
3、分析v_view的组成部分,union all上SQL select * from a, b ,c where a.id=b.id and a.tid=c.dd 测试正常
select * from ( select * from a, b ,c where a.id=b.id and a.tid=c.dd ) where aaaa=‘44444b2322424242’
union all下面的SQL查询报错了
4、分析SQL的关联字段发现e表的dd字段是varhcar2(100)，其他关联字段是number(20),感觉有眉目了，看看开发环境呢，结果也是varhcar2(100)，接着逐步看看测试库e表的dd字段是否都为数字，该表有15万行，怎么看呢，用正则表达式匹配，一时不知道怎么写。
1个小时又过去了，小姐姐第三次问情况，回答道有进展了，顺便问了问该字段是否有字符，小姐姐说肯定没有，好吧，我自己看看。
先碰碰运气吧
select max(dd),min(dd) from e测试环境显示dd有字符，开发环境则全是数字，小姐姐看到结果S了。
后面他们内部询问时，是做我们隔壁桌的一位测试小姐姐手欠输了几个英文字符导致的。

个人总结与思考

·整个过程处理完后，将个人的一些思路与不足记录如下：
1、存在沟通问题，应用详细询问是否有业务表调整导致的，业务方面和数据库应该同步排查。而不是单方面排查
2、业务设计存在问题，关联列的字段类型必须一致。
3、什么业务需要跨schema套了3层视图和一层同义词才能完成，看到这里你有什么想说的
4、第三方厂商开发了几个月居然没有DBA，给我们讲他们不需要DBA，对此你有什么想说的