虽然公司在大力的往开源的数据库上转移，但传统数据库的使用在一段时间还是会存在的，最近开发的亲们报出一个怪异的现象，就是外部传进来得字符用在末尾带有 \u0001 (在SQL SERVER 里面这又特殊的含义可以理解为char(1))，存储进 nvarchar 字符类型后会带有一个空格(其实存进char也一样)，而这样的数据在某些特殊的规则引擎或决策引擎中就会因为这多的一个空格而报错，而你去查的时候，他又不带空格。好吧 越说越乱，做个试验各位看客来看的明明白白。
大家可以注意下图，如果用len（）SQL SERVER 的传统函数来查看末尾带有空格和不带有空格的 nvarchar 或 varchar 的变量，得到的长度是一样的，要通过datalenght 来查看才能看到数据之间的不同，但大部分开发查看字符长度，都是使用 SQL SERVER len（） 并会得到一个错误结果。
而产生这个问题的主要原因是 SQL SERVER 如何比较字符的SQL SERVER 是遵循 ANSI/ISO SQL-92 规范来进行字符的比较。使得在字符处理中SQL 认为 字符串末尾带空格和 不带空格的对比 在大多数的比较中是相等的。
如果还不清晰，我们下面在做一个更直白的比较
OK 说到这里，上边带有末尾空格和不带有空格的字符串在处理中很多情况是一样的，实际上是不一样的。另外想 trim的同学 也可以省省心了，照样还是不一样。
反过来我们比对一下 POSTGRESQL ，主要的原因是有2
1 作为传统企业，或金融企业，POSTGRESQL 在收费到开源数据库转换中，会节省大量的人力物力（尤其对开发来说）
2 PG 火 （言简意赅）
PG 中是没有 NVARCHAR 这样的类型的，我们使用 VARCHAR (在SQL SERVER 中VARCHAR 也有类似上面的毛病) 和 PG的 text 类型，测试是在PG admin tools 上进行的，也是通过插入带有空格，和不带空格的数据来进测试
插入两条数据 id 为 2的是带有空格的
通过上图的比较和证明，PG可以清晰的在查询中分辨那个值里面包含空格，那些不是， PostgreSQL 版本 11 的这两种字符类型，是没有类似 SQL SREVER 那样的'坑'
这里如果我们使用PG 中的 char类型，也会出现和SQL SERVER 类似的情况，所以在使用PG 的过程中，如果可以还是尽量使用 varchar 类型 或 text 类型
结论 SQL SERVER 的空格的坑是实实在在的存在，如果要避开这个坑，光在数据库层面来搞，还是比较麻烦，并行在使用SQL SERVER 的 rtrim 函数去掉右空格也以失败告终，而POSTGRESQL varchar text 天然的屏蔽了这个问题，对于这类问题数据库本身就可以解决。从另一个侧面，也说明PG建表的字符字段，您还是尽量不要选择 CHAR 类型。
最近群里面大量的亲们，都在问PG 的 FAILOVER 以及集群的事情，这里准备集中火力来写写一些靠谱的方案和已经证实OK 的方案，至少的有三期。