关系数据库比较：SQLite vs MySQL vs PostgreSQL

简介

关系型数据库的使用已经有相当长的时间了。它们变得流行起来托了管理系统的福，关系模型被实现得相当的好，并且被证明是操作数据的好方法（特别是事务性强的应用）。

在这篇DigitalOcean文章中，我们将尝试理解一些最常用、最流行的关系型数据库管理系统（RDBMS）的内核区别。我们将会探索最底层的区别——特性与功能，它们如何工作，在哪方面更出色，以帮助程序员选择合适的RDBMS。

条目表

1. 数据库管理系统

关系型数据库管理系统
关系与数据类型
重要的和流行的关系型数据库

2. SQLite

SQLite支持的数据类型
SQLite的优势
SQLite的劣势
何时使用SQLite
何时不用SQLite

3. MySQL

MySQL支持的数据类型
MySQL的优势
MySQL的劣势
何时使用MySQL
何时不用MySQL

3. PostgreSQL

PostgreSQL支持的数据类型
PostgreSQL的优势
PostgreSQL的劣势
何时使用PostgreSQL
何时不用PostgreSQL

数据库管理系统

数据库是有组织地存储模型数据的空间，存储各种类型的信息（数据）。每个数据库，除了无模式型的，都有一个模型，提供数据的结构描述。数据库管理系统是管理数据库结构、大小和排序的应用（或库）。

关系型数据库管理系统

关系型数据库系统实现了关系模型，并用它来处理数据。关系模型在表中将信息与字段关联起来（也就是schemas），从而存储数据。

这种数据库管理系统需要结构（例如表）在存储数据之前被定义出来。有了表，每一列（字段）都存储一个不同类型（数据类型）的信息。数据库中的每个记录，都有自己唯一的key，作为属于某一表的一行，行中的每一个信息都对应了表中的一列——所有的关系一起，构成了关系模型。

关系和数据类型

关系可以被看做是包含一系列共同表示被保持数据库以及相关信息的属性的数学集合. 这种类型的识别和采集方法可以让关系型数据库以它们自己的方式运作.

在定义一个可以向其中插入数据的表时，每一个形成一条记录的元素（例如： 属性）都必须同定义的数据类型相匹配(例如：一个integer, 一个date 等等.). 不同的关系型数据库管理系统实现了不同的数据类型 — 它们不总是能直接互相转换的.

与限制的协作，就像我们之前已经介绍过的，在关系数据库的使用中是很普遍的。事实上，限制形成了关系的核心.

重要和流行的关系型数据库

本文中，我们将会介绍三种主要而且重要的开源关系型数据库管理系统，是他们影响了应用开发世界。

SQLite:

一个强大的嵌入式关系型数据库管理系统。

MySQL:

最流行的RDBMS。

PostgreSQL:

最先进SQL型开源objective-RDBMS。

注: 开源应用总是可以自由使用的。大多数时候，复制工程（利用代码）创建新应用也是被允许的。如果你对DBMS感兴趣，你可以看看一些基于这些工程的分支项目，例如MariaDB。

SQLite是非凡的数据库，他可以进程在使用它的应用中。作为一个自包含、基于文件的数据库，SQLite提供了出色的工具集，可以处理所有类型的数据，没有什么限制，而且比起服务器运行的进程型服务器使用起来轻松许多。

一个应用使用SQLite时，它的功能直接被集成在其中，应用会直接访问包含数据的文件（即SQLite数据库）,而不是通过一些端口（port, socket）来交互。感谢这种底层技术，这使SQLite变得非常快速和高效，并且十分强大。

SQLite支持的数据类型

• NULL:

NULL值。

• INTEGER:

有符号整数，按照设置用1、2、3、4、6或8字节存储。

• REAL:

浮点数，使用8字节IEEE浮点数方式存储。

• TEXT:

文本字符串，使用数据库编码存储（UTF-8, UTF-16BE 或 UTF-16LE）。

• BLOB:

二进制大对象，怎么输入就怎么存储。

SQLite 的优点

• 基于文件:

整个数据库都包含在磁盘上的一个文件中，因此它有很好的迁移性。

• 标准化:

尽管它看起来像个“简化版”的数据库，SQLite 确实支持 SQL。它略去了一些功能(RIGHT OUTER JOIN 和 FOR EACH STATEMENT)，但是，又同时增加了一些其他功能。

• 对开发乃至测试都很棒:

在绝大多数应用的开发阶段中，大部分人都非常需要解决方案能有并发的灵活性。SQLite 含有丰富功能基础，所能提供的超乎开发所需，并且简洁到只需一个文件和一个 C 链接库。

SQLite的缺点

• 没有用户管理:

高级数据库都能支持用户系统，例如，能管理数据库连接对数据库和表的访问权限。但由于 SQLite 产生的目的和本身性质（没有多用户并发的高层设计），它没有这个功能。

• 缺乏额外优化性能的灵活性：

仍然是从设计之初，SQLite 就不支持使用各种技巧来进行额外的性能优化。这个库容易配置，容易使用。既然它并不复杂，理论上就无法让它比现在更快，其实现在它已经很快了。

何时使用 SQLite ？

• 嵌入式应用:

所有需要迁移性，不需要扩展的应用，例如，单用户的本地应用，移动应用和游戏。

• 代替磁盘访问:

在很多情况下，需要频繁直接读/写磁盘文件的应用，都很适合转为使用 SQLite ，可以得益于 SQLite 使用 SQL 带来的功能性和简洁性。

• 测试:

它能秒杀大部分专门针对应用业务逻辑（也就是应用的主要目的：能完成功能）的测试。

何时不用 SQLite ？

• 多用户应用:

如果你在开发的应用需要被多用户访问，而且这些用户都用同一个数据库，那么相比 SQLite 最好还是选择一个功能完整的关系型数据库（例如 MySQL）。

• 需要大面积写入数据的应用:

SQLite 的缺陷之一是它的写入操作。这个数据库同一时间只允许一个写操作，因此吞吐量有限。

MySQL 在所有大型数据库服务器中最流行的一个. 它的特性丰富，产品的开源性质使得其驱动了线上大量的网站和应用程序. 要入手 MySQL 相对简单，开发人员可以在互联网上面访问到大量有关这个数据库的信息.

注意: 由于这个产品的普及性，大量的第三方应用、工具和集成库对于操作这个RDBCMS的方方面面大有帮助.

Mysql没有尝试去实现SQL标准的全部，而是为用户提供了很多有用的功能. 作为一个独立的数据库服务器，应用程序同Mysql守护进程的交互，告诉它去访问数据库自身 — 这一点不像 SQLite.

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:
  一个集合.

MySQL的优点

• 容易使用:

安装MySQL非常容易。第三方库，包括可视化（也就是有GUI）的库让上手使用数据库非常简单。

• 功能丰富:

MySQL 支持大部分关系型数据库应该有的 SQL 功能——有些直接支持，有些间接支持。

• 安全:

MYSQL 有很多安全特性，其中有些相当高级。

• 灵活而强大:

MySQL 能处理很多数据，此外如有需要，它还能“适应”各种规模的数据。

• 快速:

放弃支持某些标准，让 MySQL 效率更高并能使用捷径，因此带来速度的提升。

MySQL的缺点

• 已知的局限:
  从设计之初，MySQL 就没打算做到全知全能，因此它有一些功能局限，无法满足某些顶尖水平应用的需求。
• 可靠性问题:
  MySQL 对于某些功能的实现方式(例如，引用，事务，数据审核等) 使得它比其他一些关系型数据库略少了一些可靠性。
• 开发停滞:
  尽管 MySQL 理论上仍是开源产品，也有人抱怨它诞生之后更新缓慢。然而，应该注意到有一些基于 MySQL 并完整集成的数据库（如 MariaDB），在标准的 MySQL 基础上带来了额外价值。

何时使用 MySQL？

• 分布式操作:
  当SQLite所提供的不能满足你的需要时，可以把MySQL包括进你的部署栈，就像任何一个独立的数据库服务器，它会带来大量的操作自由性和一些先进的功能。
• 高安全性:
  MySQL的安全功能，用一种简单的方式为数据访问（和使用）提供了可靠的保护。
• Web网站 和 Web应用:
  绝大多数的网站（和Web应用程序）可以忽视约束性地简单工作在MySQL上。这种灵活的和可扩展的工具是易于使用和易于管理的——这被证明非常有助于长期运行。
• 定制解决方案:
  如果你工作在一个高度量身定制的解决方案上，MySQL能够很容易地尾随和执行你的规则，这要感谢其丰富的配置设置和操作模式。

何时不用 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已成为可能.

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 数据

PostgreSQL的优点

• 标准支持 SQL 的开源关系型数据库:
  PostgreSQL 是一个开源的，自由(free)的，同时非常强大的关系型数据管理系统。
• 强大的社区:
  PostgreSQL 背后有热忱而经验丰富的社区，可以通过知识库和问答网站获取支持，全天候免费。
• 强大的第三方支持:
  即使其本身功能十分强大，PostgreSQL 仍附带有许多强大的开源第三方工具来辅助系统的设计、管理和使用。
• 可扩展性:
  可以用预先存储的流程来程序性扩展 PostgreSQL ，一个高级的关系型数据库理应如此。
• 面向对象:
  PostgreSQL 不只是一个关系型数据库，还是一个面向对象数据库——支持嵌套，及一些其他功能。

PostgreSQL的缺点：

• 性能:
  对于简单而繁重的读取操作, PostgreSQL 会小题大作而可能会出现比同行（如MySQL）更低的性能。
• 普及:
  根据该工具的性质，从普及度来说它还缺乏足够后台支撑，尽管有大量的部署——这可能会影响能够获得支持的容易程度。
• 托管:
  由于上述因素的影响，要让主机或服务提供商提出使用PostgreSQL实例是很难的。

何时使用PostgreSQL？

数据完整性: 当可靠性和数据完整性是绝对必要而无需理由时，PostgreSQL是更好的选择。

复杂的自定义过程: 如果你需要你的数据库执行自定义过程，可扩展的PostgreSQL是更好的选择。

整合: 在将来，如果可能要把整个数据库系统迁移到另一个适当的解决方案（例如Oracle）中，PostgreSQL对于这种切换将是最兼容和易于操作的。

复杂的设计:
相比其他的开源和自由的 RDBMS（关系数据库管理系统）实现来说，对于复杂的数据库设计，PostgreSQL提供了大部分的功能和可能性，同时并没放弃其他有价值的地方。

何时不用 PostgreSQL？

• 速度:
  如果你需要的只是快速的读取操作, PostgreSQL 不是为此而准备的工具。
• 简化体制:
  除非你需要绝对的数据完整性，原子性，一致性，隔离性，耐久性，或复杂的设计，PostgreSQL 对简化体制来说是杀手。
• 复制:
  除非你愿意花不少时间，精力和资源，否则对于那些缺乏数据库和系统管理经验的人来说，实现与MySQL的（主从）复制可能不容易。

本文转自开源中国，参与翻译(4人)：赵亮-碧海情天, 戴仓薯, realZ, leoxu

End.

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。