Dont Do This in PostgreSQL

可以看德哥这篇文章，使用这个编码后就是给啥存啥，如果 db 用户瞎用，里面 gbk utf8 都往里放，那将来用的时候会比较麻烦，而且这样舍弃了数据库提供的数据检查功能，不是浪费么。

主要就是 psql 实际会自动处理这个事情的，如果需要密码会找你要的。不用强制让他提示你输入密码。

可以使用 trigger 代替。

CREATE TABLE computer (
    hostname        text,    -- indexed
    manufacturer    text     -- indexed
);

CREATE TABLE software (
    software        text,    -- indexed
    hostname        text     -- indexed
);

DELETE FROM software WHERE hostname = $1;

CREATE RULE computer_del AS ON DELETE TO computer
    DO DELETE FROM software WHERE hostname = OLD.hostname;

DELETE FROM computer WHERE hostname = 'mypc.local.net';

DELETE FROM software WHERE computer.hostname = 'mypc.local.net'
                       AND software.hostname = computer.hostname;

Nestloop
  ->  Index Scan using comp_hostidx on computer
  ->  Index Scan using soft_hostidx on software

DELETE FROM computer WHERE hostname >= 'old'
                       AND hostname <  'ole'

DELETE FROM software WHERE computer.hostname >= 'old' AND computer.hostname < 'ole'
                       AND software.hostname = computer.hostname;

Hash Join
  ->  Seq Scan on software
  ->  Hash
    ->  Index Scan using comp_hostidx on computer

DELETE FROM computer WHERE hostname ~ '^old';

Nestloop
  ->  Index Scan using comp_hostidx on computer
  ->  Index Scan using soft_hostidx on software

DELETE FROM computer WHERE manufacturer = 'bim';

DELETE FROM software WHERE computer.manufacturer = 'bim'
                       AND software.hostname = computer.hostname;

Nestloop
  ->  Index Scan using comp_manufidx on computer
  ->  Index Scan using soft_hostidx on software

使用外键来代替表继承。

现在表分区已经是 native 支持了，不用使用表继承来实现了。在维护某些历史表的情况下使用表继承可以避免使用 union all 获得全部数据，但是也有一些坑，比如查询的时候可能会需要特别指定是不是需要子表的数据，要不即使只想查父表里面的数据的时候也可能会触发子表的扫描，浪费时间。

1. not in 语句里面如果有 null 那会导致一行数据都不能返回。
2. 会导致查询规划器无法很好的执行 sql。一般会有两种情况，一种是哈希子查询(hashed subplan)，一种是一般子查询(plain subplan)。哈希子查询比较快，但是限于数据了不能太大。一般子查询就很糟糕了，是个 O(n^2) 复杂度的操作。

就是不要用 NamesLikeThis 使用 names_like_this。

pg 里面会使用小写字母做表名，除非使用了 "" ，例如 Foo 会创建 foo，"Bar" 会创建 Bar 。这样查的时候对于 "Foo", Bar, bar 这几个名字都会报找不到表（那个 Bar 找不到是因为每家引号）。

有时候在报表里面可能想要名字显示的好看一点，那可以使用 as 来起个别名。

例如下面这个

SELECT * FROM blah WHERE timestampcol BETWEEN '2018-06-01' AND '2018-06-08'

对于 2018-06-08 00:00:00.000000 也是符合的。使用下面的查询会好一点

SELECT * FROM blah WHERE timestampcol >= '2018-06-01' AND timestampcol < '2018-06-08'

对于 int 和 date 类型可能问题不大。

使用 timestamptz 来存时间。不带时区的一旦涉及到时区相关的运算就会比较麻烦了，你总是需要指定你时间的时区。如果你不打算进行什么运算，只是存一下，也可以使用 timestamp.

和上面那个类似吧。

使用 timestamptz 代替。

使用下面的代替：

1. 带时区的 timestamp：CURRENT_TIMESTAMP 或者 now()
2. 不带时区的：LOCALTIMESTAMP
3. 只需要日期：CURRENT_DATE
4. 只需要时间：LOCALTIME

因为 CURRENT_TIME 会返回一个 timetz 类型的数据。

不要指定精度，尤其是 0。使用 date_trunc('second', xxx) 来代替。

因为指定精度会使用 round 方式而不是通常认为的 truncate 方式来处理，例如你使用 now() 的时候可能会产生一个未来半秒之后的时间。

使用 text 代替。

char(n) 对于不足的部分会使用空数据不足，这会浪费空间，并且也并不会让查询变快。并且 char(n) 还不是个固定长度的类型，不同的字符的 byte 长度不同。

即使是定长的字符串也不要用 char(n)，例如国家代码，hash 值，标识符啥的。使用 text 或者 domain over text，加约束 CHECK(length(VALUE)=3) 或者 CHECK(VALUE ~ '^[[[[:alpha:]]]]{3}$') 或者其他类似的。

因为 char(n) 并不检查长度，只是会补齐。使用 char(n) 并不会比 varchar(n) 有什么性能上面的提升。反过来反而是会提升。另外，如果查询的时候传入的数据类型是个 text 或者 varchar 的话就用不上索引了。

使用不指定长度的 varchar() 或者 text 代替。

varchar(n) 在插入长度超过 n 的字符的时候会报错。varchar() 或者 text 没有长度限制。存相同长度的字符的时候，他们三个占用的空间是一样的，性能也没区别。

如果你确实需要长度限制，那么 varchar(n) 也挺好的，但是比如你用 varchar(20) 来存名字，某天可能一个名字巨长的人来了，他就不能注册了。

如果你需要限制长度，那通常不止需要最大长度，也会需要限制最小长度，那使用 check 约束比较好。

只处理一种货币类型，也不要处理分级别的 cents，并且只加减操作的话，可以试试看。

这个我补充下：一般有建议是把金额放大成整数，只操作整数。这样可以避免无意义的小数，比如 0.011 元这个钱在现实世界里面是不存在的，只有 0.01 是有意义的。另外计算机世界里面浮点数的乘法和除法可能会出来 0.010000008 这样的金额的，也是无意义的。所以有一个建议就是把金额映射成 100 倍，存成整数，比如 0.01 元，存成 1。按说未来只有通货膨胀了，紧缩出现更小面额的可能性也不大，或者也可以考虑放大 1000 倍什么的。。。

10 增加了 identity 类型，

GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY [ ( sequence_options ) ]

类似原来的 serial， 会创建一个 sequence 关联到这个字段，新插入的行会自动产生值。

ALWAYS 和 BY DEFAULT 用来指定用户如果指定了一个值的时候怎么处理。设置成 ALWAYS 的话只有在 INSERT 的时候指定 overriding system value 才能。对于 BY DEFAULT，用户指定的优先。对于 COPY 命令总是会使用用户指定的。

新的 identity 符合 sql 标准。老的 serial 类型有一些小问题，导致管理稍微有些麻烦。比如你需要单独给对应的 sequance 权限之后，用户才能真的对这个表插入。具体可以看这个。

特别是这样，会允许网络上的其他人连接你的数据库，还可以使用超级用户。

host all all 0.0.0.0/0 trust