一、MySQL
MySQL 在所有大型数据库服务器中最流行的一个. 它的特性丰富，产品的开源性质使得其驱动了线上大量的网站和应用程序. 要入手 MySQL 相对简单，开发人员可以在互联网上面访问到大量有关这个数据库的信息.
注意: 由于这个产品的普及性，大量的第三方应用、工具和集成库对于操作这个RDBCMS的方方面面大有帮助.
Mysql没有尝试去实现SQL标准的全部，而是为用户提供了很多有用的功能. 作为一个独立的数据库服务器，应用程序同Mysql守护进程的交互，告诉它去访问数据库自身 -- 这一点不像 SQLite.
1、MySQL支持的数据类型
| TINYINT | 一个非常小的整数 |
| SMALLINT | 一个小整数 |
| MEDIUMINT | 一个中间大小的整数 |
| INT or INTEGER | 一个正常大小的整数 |
| BIGINT | 一个大的整数 |
| FLOAT | 一个小的 (单精度) 浮点数，不能是无符号的那种 |
| DOUBLE, DOUBLE PRECISION, REAL | 一个正常大小 (双精度) 的浮点数，不能使无符号的那种 |
| DECIMAL, NUMERIC | 没有被包装的浮点数。不能使无符号的那种 |
| DATE | 一个日期 |
| DATETIME | 一个日期和时间的组合 |
| TIMESTAMP | 一个时间戳 |
| TIME | 一个时间 |
| YEAR | 一个用两位或者4位数字格式表示的年份(默认是4位) |
| CHAR | 一个固定长度的字符串，存储时总是在其固定长度的空间里右对齐 |
| VARCHAR | 一个可变长度的字符串 |
| TINYBLOB, TINYTEXT | 一个BLOB或者TEXT列，最大长度255 (2^8 - 1)个字符 |
| BLOB, TEXT | 一个BLOB或者TEXT列，最大长度 65535 (2^16 - 1)个字符 |
| MEDIUMBLOB, MEDIUMTEXT | 一个BLOB或者TEXT列，最大长度 16777215 (2^24 - 1)个字符 |
| LONGBLOB, LONGTEXT | 一个BLOB或者TEXT列，最大长度4294967295 (2^32 - 1) 个字符 |
| ENUM | 一个枚举类型 |
| SET | 一个集合 |
2、MySQL的优点
| 容易使用 | 安装MySQL非常容易。第三方库，包括可视化（也就是有GUI）的库让上手使用数据库非常简单 |
| 功能丰富 | MySQL 支持大部分关系型数据库应该有的 SQL 功能——有些直接支持，有些间接支持 |
| 安全 | MYSQL 有很多安全特性，其中有些相当高级 |
| 灵活而强大 | MySQL 能处理很多数据，此外如有需要，它还能“适应”各种规模的数据 |
| 快速 | 放弃支持某些标准，让 MySQL 效率更高并能使用捷径，因此带来速度的提升 |
3、MySQL的缺点
| 已知的局限 | 从设计之初，MySQL 就没打算做到全知全能，因此它有一些功能局限，无法满足某些顶尖水平应用的需求 |
| 可靠性问题 | MySQL 对于某些功能的实现方式(例如，引用，事务，数据审核等) 使得它比其他一些关系型数据库略少了一些可靠性 |
| 开发停滞 | 尽管 MySQL 理论上仍是开源产品，也有人抱怨它诞生之后更新缓慢。然而，应该注意到有一些基于 MySQL 并完整集成的数据库（如 MariaDB），在标准的 MySQL 基础上带来了额外价值 |
4、何时使用 MySQL？
| 分布式操作 | 当你需要的比SQLite可以提供的更多时，把MySQL包括进你的部署栈，就像任何一个独立的数据库服务器，会带来大量的操作自由和一些先进的功能 |
| 高安全性 | MySQL的安全功能，用一种简单的方式为数据访问（和使用）提供了可靠的保护 |
| Web网站 和 Web应用 | 绝大多数的网站（和Web应用程序）可以忽视约束性地简单工作在MySQL上。这种灵活的和可扩展的工具是易于使用和易于管理的——这被证明非常有助于长期运行 |
| 定制解决方案 | 如果你工作在一个高度量身定制的解决方案上，MySQL能够很容易地尾随和执行你的规则，这要感谢其丰富的配置设置和操作模式 |
5、何时不用 MySQL？
| SQL 服从性 | 因为 MySQL 没有[想要]实现 SQL 的全部标准，所以这个工具不完全符合SQL。如果你需要对这样的关系数据库管理系统进行整合，从MySQL进行切换是不容易的 |
| 并发 | 即使MySQL和一些存储引擎能够真地很好执行读取操作，但并发读写还是有问题的 |
| 缺乏特色 | 再次提及，根据数据库引擎的选择标准，MySQL会缺乏一定的特性，如全文搜索 |
二、PostgreSQL
PostgreSQL 是一个先进的，开放源代码的[对象]-关系型数据库管理系统，它的主要目标是实现标准和可扩展性. PostgreSQL, 或者说是 Postgres, 试图把对 ANSI/ISO SQL标准的采用与修正结合起来.
对比其他的RDBMS, PostgreSQL以它对于对象-关系和或关系型数据库功能，比如对于可靠事务，例如原子性，一致性，隔离性和持久性（ACID）的完全支持，这些东西的高度需求和集合的支持，以示其独特性.
由于强大的底层技术, Postgres对于高效的完成许多处理任务很有一手. 得益于其多版本并发控制 (MVCC)的实现，在没有读取锁的前提下也能达成并发, 这也同样确保了ACID的实施.
PostgreSQL是高度可编程的, 因而可以使用被称作“存储过程”的自定义程序进行扩展. 这些功能可以被创建用来简化一个写重复、复杂并且常常需要数据库操作的任务的执行.
虽然特性强大，但这个 DBMS并没有MySQL那么流行, 可还是有许多迷人的第三方工具和库被设计出来用于使得对PostgreSQL的操作简化. 如今通过许多操作系统默认的包管理器轻松的获取PostgreSQL已成为可能.
1、PostgreSQL支持的数据类型
| bigint | 有符号的八位整数 |
| bigserial | 自增长的八位整数 |
| bit [(n)] | 固定长度的位串 |
| bit varying [(n)] | 可变长度的位串 |
| boolean | 逻辑布尔值(true/false) |
| box | 在一个平面上的矩形框 |
| bytea | 二进制数据("位数组") |
| character varying [(n)] | 可变长度的字符串 |
| character [(n)] | 固定长度的字符串 |
| cidr | IPv4 或者 IPv6 网络地址 |
| circle | 平面上的一个圆 |
| date | 日历日期 ( 年月日) |
| double precision | 双精度浮点数（8位） |
| inet | IPv4 或者 IPv6 主机地址 |
| integer | 有符号的四位整数 |
| interval [fields] [(p)] | 时间跨度 |
| line | 平面上的一个无限长的直线 |
| lseg | 平面上的一个线段 |
| macaddr | MAC (媒体访问控制)地址 |
| money | 货币金额 |
| numeric [(p, s)] | 可选精度的精确数字 |
| path | 一个平面上的几何路径 |
| point | 一个平面上的几何点 |
| polygon | 一个平面上的闭合的几何路径 |
| real | 单精度浮点数(4 位) |
| smallint | 有符号的两位整数 |
| serial | 自增长4位整数 |
| text | 可变长度字符创 |
| time [(p)] [without time zone] | 一天中的时间(无时区) |
| time [(p)] with time zone | 一天中的时间，包含时区 |
| timestamp [(p)] [without time zone] | 日期和时间（没有时区） |
| timestamp [(p)] with time zone | 日期和时间，包含时区 |
| tsquery | 文本搜索查询 |
| tsvector | 文本搜索文档 |
| txid_snapshot | 用户级事务ID快照 |
| uuid | 通用的唯一标识符 |
| xml | XML 数据 |
2、PostgreSQL的优点
| 标准支持 SQL 的开源关系型数据库 | PostgreSQL 是一个开源的，免费的，同时非常强大的关系型数据管理系统 |
| 强大的社区 | PostgreSQL 背后有热忱而经验丰富的社区，可以通过知识库和问答网站获取支持，全天候免费 |
| 强大的第三方支持 | 即使其本身功能十分强大，PostgreSQL 仍附带有许多强大的开源第三方工具来辅助系统的设计、管理和使用 |
| 可扩展性 | 可以用预先存储的流程来程序性扩展 PostgreSQL ，一个高级的关系型数据库理应如此 |
| 面向对象 | PostgreSQL 不只是一个关系型数据库，还是一个面向对象数据库——支持嵌套，及一些其他功能 |
3、PostgreSQL的缺点：
| 性能 | 对于简单而繁重的读取操作, 超过了 PostgreSQL 的杀伤力，可能会出现比同行（如MySQL）更低的性能 |
| 普及 | 按给出的该工具的性质，从普及度来说它还缺乏足够后台支撑，尽管有大量的部署——这可能会影响能够获得支持的容易程度 |
| 托管 | 由于上述因素的影响，要让主机或服务提供商提出使用PostgreSQL实例是很难的 |
4、何时使用PostgreSQL？
| 数据完整性 | 当可靠性和数据完整性是绝对必要而无需理由时，PostgreSQL是更好的选择 |
| 复杂的自定义过程 | 如果你需要你的数据库执行自定义过程，可扩展的PostgreSQL是更好的选择 |
| 整合 | 在将来，如果可能要把整个数据库系统迁移到另一个适当的解决方案（例如Oracle）中，PostgreSQL对于这种切换将是最兼容和易于操作的 |
| 复杂的设计 | 相比其他的开源和免费的 RDBMS（关系数据库管理系统）实现来说，对于复杂的数据库设计，PostgreSQL提供了大部分的功能和可能性，同时并没放弃其他有价值的地方 |
5、何时不用 PostgreSQL？
| 速度 | 如果你需要的只是快速的读取操作, PostgreSQL 不是为此而准备的工具 |
| 简化体制 | 除非你需要绝对的数据完整性，原子性，一致性，隔离性，耐久性，或复杂的设计，PostgreSQL 对简化体制来说是杀手 |
| 复制 | 除非你愿意花不少时间，精力和资源，否则对于那些缺乏数据库和系统管理经验的人来说，实现与MySQL的（主从）复制可能不容易 |