其实每种数据库都有自己的特色,PostgreSQL 也不例外,其中如果你留心PostgreSQL被最常问及的问题之一,就是大小写的问题。今天的讨论不涉及数据库名,表名的大小写,仅仅讨论一下字段里面的值的大小写。
我们以一个例子为开始,
1 我们创建一个表
create table Case_insensitive
( id serial not null primary key,
address varchar(50),
comment text);
2 将数据库输入到里面
insert into case_insensitive (address,comment) values ('Person1@em.com','Thanks for your help!!');
insert into case_insensitive (address,comment) values ('TaTk@bb.com','I hate it');
insert into case_insensitive (address,comment) values ('ttKbb@cc.com','Sorry I am understanding now, little slowly');
那么大小写的问题在哪里?我们来查询一个数据大致你就会理解
从图中你可以清晰的看到,发生的问题在哪里,如果你的字段里面的值是包含英文大小写的情况下,你必须是要进行细致一致的大小写匹配才能找到相关的值。
而按照中国的人的思维方式,或者说用惯了其他主流数据库的情况下这样的必须匹配性的输入对中国人来说,是不友好的。
虽然题目中提到了"坑", 但实际上来说,这不是一个坑,或者严谨的来说,PostgreSQL这样的方式才应该是正确的。而很多时候先入为主,来判断POSTGRESQL 在这方面是有坑的,这并不公平。
那如何来解决这个世俗认为postgresql 应该和其他数据库一样使用习惯的方式问题。下面就要来说一说。
方法:1
统一规则:
我们将我们查询的字段,和需要查询的数据统一变成小写,通过 lower 这个函数来进行统一的转换。
从上图可以看出,我们可以将数据在输入纯小写的情况下,将数据查出。
问题又来了,这样的情况下能走索引吗?
答案是当然不能,函数的计算在条件左边的情况下大部分数据库都是不能走索引的,oracle 当然有类似的功能,能让一部分这样的情况走索引。PG 可以吗,当然,对标的就是ORACLE ,当然也可以当函数计算在左边的情况下,继续走索引。
怎么做???
变换思路,我们将索引的里面的字符都变小就可以了,看下图。
当然后面执行计划还未走索引得原因是数据量只有三条,不足以支撑走索引的cost.
那处理这样情况的方法到此为止了? no no no 我们还有其他的方法供您选择。
2 有一种情况是,这一列例如是邮件地址,如果是邮件地址的情况下,是具有一种性质的,就是数据的唯一性。那如果 (请看图)
如果出现图中的情况,这可是不大美好的一件事情。如何来进行邮件地址的唯一性检查。我们可以提前为这列,建立一个唯一索引。
有了这样的索引大小写不一致的情况输入同样的字符就可以被管制了
当然如果这些你还有疑问,看看是不是还有其他的方法来对这样的事情进行处理。回答是YES
3 使用ilike
通过使用ilike的查询方式来查询大小写敏感的问题。
其实如果有规划的情况下,可以通过在输入时候的大小写输入的转换在insert 这个阶段就将问题处理清楚,并且辅助于一些约束。这样问题就比较好解决。