POSTGRESQL 学习有感，向左灵活多变，向右容器化

最近学习POSTGRESQL 看完某本书，突然有所顿悟，数据库到底应该是功能多，能减低开发的难度，还是功能缺乏，通过第三方的元素来给自己加持。

之前我是MYSQL 狂热的拥护者，分库分表， 中间件，各种开源组件，数据融合的手段，怎么针对24小时的系统，大表安全添加索引 字段，觉得很高大上，SQL SERVER 和 ORACLE 都是渣渣辉。

这就样引入了一个问题数据库到底是容器化好，还是功能特多，满足各种应用和开发的需求好。可能会有人问，你说POSTGRESQL 这个好那个好，到底有多少公司在用，为什么MYSQL 还是那么多公司在用。

我其实想问一个问题，糖很好吃，人人都爱吃甜的（至少说爱吃苦的，会被视为不正常），那糖就一定是好的？

或许三个字，习惯了，随大流，能解释，为什么很多传统公司，在去O的道路上，并不太愉快，或许即使因为这三个字，而忽略了自己真实的需求。人家行，未必你行，原因也很简单，因为技术投入比，人家花5万请一个高级的DB 架构，你花8000请一个MYSQL 的DBA ，那能一样吗？ 

话题扯远了，回到最近的学习

这里引入一段书中的文字

模式：schema

模式是数据库领域的一个基本概念，有些数据库把模式和用户合二为一，POSTGRESQL 不同，POSTGRESQL 是具有清晰的模式定义。模式可以理解为一个命名的空间或目录，不同的模式下可以有相同的名称的表，函数等对象而不产生冲突，提供模式这个概念是为了便于管理。

MYSQL 数据库没有schema

ORACLE 有schema 

SQL SERVER 有schema

POSTGRESQL 有schema

即使是有，PG 的schema 是建立在数据库概念上的， 画一个图来总结一下这些数据库的schema  (SQL SERVER 类似 PG，就不在画图了)

从管理的角度来说， PG 的对于database 的概念和 schema 的概念是融合了ORACLE 和 MYSQL 两种数据库的概念。

那么如果一个MYSQL 的INSTANCE 下有多个MYSQL 的DATABASE 到PG 应该使用PG 的schema 的概念， 建立一个数据库，然后通过schema 的概念来管理表。这样避免PG 中多个数据库不能直接访问的问题。

那么说到另外一个问题，schema 哪个是默认的schema PG 默认的schema是public ,哪个用户都有权利在public建立任何的OBJECT， 这点类似SQL SERVER DBO的 schema。但后面对于模式的搜索路径的解决方法里面，PG 是可以设置相关的相关数据库哪个schema 是默认被应用的，也就是你输入表名，默认去搜寻哪个schema。这点SQL SERVER 是没有相关的选择性的。

另外对于一些表关于性能的问题，PG 考虑的也是比较多，例如如果我的一个表只是存储临时的数据，但速度需要很快，对于这些临时数据，如果数据库系统出现问题，丢失在内存还未刷入到磁盘的情况我也能接受，这样的情况下，PG 也提供了 unlogged 表，这个表天生不需要写入 WAL LOG ，数据会直接写入数据文件，损失了一些数据的安全性，成全了性能。

如果这点在MYSQL上，是很难实现的，因为MYSQL是针对整个数据库的表，我可以设置 binlog = 0 ,此时不记录任何的BINLOG ，但对于整体表这样操作，意义不大，那如果我希望MYSQL的性能超级高，不需要写入BINLOG ，那我唯一能做的是建立一个MYSQL数据库并且对于这个数据库不记录BINLOG 的设置，但这样操作显然对于需求有点太大了，并且也直接影响到这个数据库的复制，或者高可用，这就有点大题小做了。

所以随着深入学习PG，发现PG的灵活性的确是很高，并且管理方面也有自己融合各家数据库的方式。对比就是MYSQL的容器化的问题，很多事情都需要在数据库外成型，这点的确对于某些传统行业的数据库使用带来了麻烦。

这里并没有要说MYSQL 的容器化不好，如同糖和盐，都是必不可少的东西，数据库本身没有错，错的是不懂的人，在错误的时间，错误的环境，选择了错误的数据库，导致一系列问题。