提供：ZStack云计算

内容介绍

关系数据库的历史相当悠久，而其崛起要归功于关系模型的广泛普及，特别是在关键性数据处理领域的应用。

在本教程中，我们将探讨几种高人气关系数据库管理系统（简称RDBMS）间的异同，并探索它们在特性与功能方面的差别，从而更为科学地选择合适的数据库方案。

词汇表

1. 数据库管理系统

1. 关系数据库管理系统
2. 关系与数据类型
3. 热门与重要关系数据库

2. SQLite

1. SQLite所支持的数据类型
2. SQLite的优势
3. SQLite的缺点
4. 何时使用SQLite
5. 何时不适合使用SQLite

3. MySQL

1. MySQL支持的数据类型
2. MySQL的优势
3. MySQL的缺点
4. 何时使用MySQL
5. 何时不适合使用MySQL

4. PostgreSQL

1. PostgreSQL支持的数据类型
2. PostgreSQL的优势
3. PostgreSQL的缺点
4. 何时使用PostgreSQL
5. 何时不适合使用PostgreSQL

数据库管理系统

数据库负责以逻辑方式建立存储空间模型，从而容纳各类不同信息（数据）。每种数据库(除无模式数据库）都提供数据处理结构。数据库管理系统则属于对不同种类及大小的数据库进行管理的应用（或者库）。

注意：要了解更多与数据库管理系统相关的内容，请参阅了解数据库一文。

关系数据库管理系统

关系数据库系统负责实现用于数据处理的关系模型。关系模型通过将数据定义为表内属性的相关条目来实现存储信息塑造。

这类数据库管理系统要求其结构（例如表）必须进行定义，从而容纳并处理数据。在表中，每一列（例如属性）都容纳一种不同类型的信息（例如数据类型）。而数据库中的每条记录都以key作为惟一标识，借此将其翻译为归属于表内的某一行。各行的属性序列共同构成表内的一列——这些元素组合起来，就成为完整的关系模型。

关系与数据类型

关系可以理解为一系列共同代表数据库与所保存信息的属性系列。这种识别与收集方法类型正是关系数据库的起效基础。

在定义某表进行插入记录时，每个构成记录的元素（即属性）都必须匹配所定义的数据类型（例如整数或数据等）。不同的关系数据库管理系统采用不同的数据类型——且其有时无法直接互换。

正如我们之前所提到，关系数据库往往需要遵循多种约束条件。事实上，约束条件构成了关系的核心所在。

注意：如果大家需要处理与工作无关的随机信息（例如文件），那么比较适合使用NoSQL（无模式数据库）。如果大家对此抱有兴趣，请参阅NoSQL数据库管理系统对比。

热门与重要关系数据库

在本教程中，我们将介绍三款高人气且重要的开源关系数据库管理系统。

• SQLite:

一套非常强大的嵌入式关系数据库管理系统。

• MySQL:

最为强大且应用广泛的RDBMS。

• PostgreSQL:

最先进且兼容SQL的开源对象型RDBMS。

注意：开源应用绝大多数供大家免费使用。如果大家对DBMS感兴趣，不妨了解更多fork项目，例如MariaDB。

SQLite

SQLite是一套出色的库，以嵌入应用的方式起效。作为一款独立的、基于文件的数据库，SQLite提供一系列强大工具以处理各类数据，约束较少且较托管型、基于进程（服务器）的关系数据库更为易用。

当应用使用SQLite时，其以整合方式实现功能并直接包含数据的文件（即SQLite数据库），而非通过各类接口（即端口与套接）进行通信。通过这种方式，SQLite拥有极为出色的速度与效率表现。

SQLite支持的数据类型

• NULL:

NULL值。

• INTEGER:

包含符号的整数，根据具体值大小存储为1、2、3、4、6或8字节中。

• REAL:

浮点值，存储为一个8字节IEEE浮点数。

• TEXT:

文本字符串，利用数据库编码（UTF-8、UTF-16BE或者UTF-16LE）进行存储。

• BLOB:

数据blob，作为输入结果直接存储。

注意：要了解更多与SQLite数据类型与SQLite类型亲和力相关的内容，请参阅官方说明文档。

SQLite的优势

• 基于文件:

整套数据库由磁盘上的单一文件构成，从而实现良好的可移植性。

• 标准识别:

尽管看似较为简单的数据库实现方案，但SQLite同样使用SQL。其省略了一些功能（RIGHT OUTER JOIN与FOR EACH STATEMENT等），但同时也增添了其它一些功能。

• 适于开发及测试：

在大多数应用的开发过程中，人们往往需要一套解决方案实现其并发扩展。SQLite凭借着自身丰富的功能集，能够满足各类开发需求，同时将一切数据融入单一文件且提供基于C的链接库。

SQLite的缺点

• 不具备用户管理机制:

先进数据库往往提供用户支持能力，例如对各数据库及表的访问权限做出管理。但SQLite由于自身特性及用途所限，不提供此类功能。

• 缺少额外性能提升空间：

同样是由于设计所限，SQLite无法实现额外的性能调整。其库易于调整及易于使用，但正是由于这一简单性，其从技术角度不可能进一步改善——但必须强调，其默认性能已经非常出色。

何时使用SQLite

• 嵌入式应用:

所有无需扩展且需要移植的应用，例如单用户本地应用、移动应用或者游戏。

• 磁盘访问更换：

多数情况下，需要面向磁盘直接读取/写入文件的应用能够从SQLite中发挥结构化查询语言（SQL）的各类功能与便利性。

• 测试:

可对大多数应用进行业务逻辑测试（即应用的主要作用：功能）。

何时不适合使用SQLite

• 多用户应用:

如果大家需要构建多客户端访问且立足同一数据库的应用，那么功能刘备的RDBM（例如MySQL）更为合适。

• 要求大量写入的应用:

SQLite的一大缺点在于写入操作能力较差。此DBMS只允许同时存在一项写入操作，因此数据吞吐能力有限。

MySQL

MySQL是目前人气最高且应用最为广泛的数据库服务器。其功能丰富，且作为开源产品支持多种网站及应用。MySQL易于上手，开发者能够通过互联网找到大量关于该数据库的信息。

注意：由于该产品人气极高，因此拥有大量与之配合的第三方应用、工具与集成库可供选择。

尽管并未实现全部SQL标准，但MySQL仍然提供相当丰富的功能。作为独立数据库服务器，各应用能够与MySQL守护进程通信以访问数据库本身——这一点与SQLite不同。

MySQL支持数据类型

• TINYINT:

极小整数。

• SMALLINT:

较小整数。

• MEDIUMINT:

中等整数。

• INT或INTEGER:

正常整数。

• BIGINT:

大型整数。

• FLOAT:

较小（单精度）浮点数。必须搭配符号。

• DOUBLE, DOUBLE PRECISION, REAL:

中等大小（双精度）浮点数。必须搭配符号。

• DECIMAL, NUMERIC:

无封装浮点数，必须搭配符号。

• DATE:

日期。

• DATETIME:

日期与时间结合。

• TIMESTAMP:

时间戳。

• TIME:

时间。

• YEAR:

年份，由2或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中的特定功能处理方式（例如引用、事务与审计）相较于其它RDBMS在可靠性方面较为薄弱。

• 发展停滞:

尽管MySQL仍然是一款开源产品，但其基于MySQL构建因此存在一定法律争论。MySQL标准安装版本之上的其它衍生成果还包括MariaDB等等。

何时使用MySQL

• 分布式操作:

如果大家需要的功能超出SQLite的范畴，则可将MySQL作为独立数据库服务器纳入部署堆栈，从而提供更多易于使用的先进功能。

• 高安全性:

MySQL的安全功能能够轻松为数据访问与使用提供安全功能。

• 网站与Web应用:

大多数网站与Web应用都能够与MySQL顺畅协作。这款灵活且具备一定扩展能力的工具易于使用及管理，适合长期运行并维护。

• 定制化解决方案:

如果大家需要一套高度定制的特定解决方案，MySQL凭借着丰富的配置设置及操作模式足以成为理想的选项。

何时不适合使用MySQL

• SQL合规性:

由于MySQL并不适合实现完整的SQL标准，因此这款工具并完全符合SQL合规要求。如果大家需要使用此类RDBMS，则应选择其它方案。

• 并发性:

尽管MySQL与某些存储引擎能够实现良好的读取操作，但并发读取-写入操作可能效果不佳。

• 功能缺失:

MySQL缺少特定功能，例如全文搜索。

PostgreSQL

PostgreSQL是一款高级开源对象关系数据库管理系统，其主要目标指向标准合规与可扩展能力。PostgreSQL，或者简称Postgres，采用并修订各项ANSI/ISO SQL标准。

相较于其它RDBMS，PostgreSQL的特色在于支持各类面向对象及/或关系数据库功能，例如事务可靠性，即原子性、一致性、隔离性与持久性（简称ACID）。

由于具备强大的底层技术，Postgres能够高效处理多种任务。由于其采用多版本并发控制（简称MVCC）机制，因此拥有良好的并发性能，同时确保ACID原则。

PostgreSQL为高度可编程数据库，因此具备良好的扩展能力，各类定制化规程被称为“存储规程”。用户可以创建此类功能以简化需要重复的、复杂的数据库操作。

尽管此DBMS不像MySQL那样知名，但仍有大量第三方工具及库可与之协作。如今PostgreSQL已经成为多种操作系统默认软件包管理器内的组成部分。

PostgreSQL支持的数据类型

• bigint:

带符号的8字节整数

• bigserial:

自增8字节整数

• bit [(n)]:

固定长度的bit串

• bit varying [(n)]:

可变长度的bit串

• boolean:

逻辑Boolean(true/false)

• box:

平面上的矩形框

• bytea:

二进制数据(“byte array（字节数组）”)

• character varying [(n)]:

可变长度字符串

• character [(n)]:

固定长度字符串

• cidr:

IPv4或IPv6网络地址

• circle:

平面上的循环

• date:

日历日期（年、月、日）

• double precision:

双精度浮点数（8字节）

• inet:

IPv4或IPv6主机地址

• integer:

带符号4字节整数

• interval [fields] [(p)]:

时间跨度

• line:

平面上的无限延长线

• lseg:

平面上的线段

• macaddr:

MAC(媒体访问控制)地址

• money:

货币金额

• numeric [(p, s)]:

可选精度精确数字

• path:

平面上的几何路径

• point:

平面上的几何点

• polygon:

平面上的闭合几何路径

• real:

单精度浮点数（4字节）

• smallint:

有符号2字节整数

• 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标准合规RDBMS：

PostgreSQL是一款开源、免费但还不够强大的关系数据库管理系统。

• 强大的社区:

PostgreSQL背后拥有忠诚且经验丰富的技术社区，能够全天候为用户免费提供专业知识支持。

• 强大的第三方支持:

除了先进的自身功能之外，PostgreSQL还拥有大量出色的开源第三方工具，能够帮助其完成管理系统的设计、管理与使用。

• 可扩展性:

PostgreSQL可利用存储规程实现编程化扩展，这也是先进RDBMS的必要能力之一。

• 对象性:

PostgreSQL并不只是一套关系数据库管理系统，同时亦拥有对象性——支持嵌套等特性。

PostgreSQL的缺点

• 性能:

对于读取操作强度较大的应用，PostgreSQL显得不太擅长，性能水平远低于MySQL等解决方案。

• 人气:

由于此工具的定位，其缺少广泛的受众基础。尽管部署较为广泛，但仍然可能影响技术支持的丰富性。

• 托管支持:

由于以上原因，用户往往较难找到合适的PostgreSQL实例托管或服务供应商。

何时使用PostgreSQL

• 数据完整性:

当可靠性与数据完整性最为优先时，PostgreSQL绝对是更好的选择。

• 复制的定制化规程:

如果大家希望自己的数据库能够执行定制化规程，PostgreSQL比较适合。

• 集成性:

未来如果有必要对整体数据库系统进行迁移，PostgreSQL拥有出色的合规性且易于完成转换。

• 复杂的设计:

相较于其它开源与免费RDBMS实现方案，PostgreSQL提供的大部分功能与机制能够很好地承载复杂的实际需求。

何时不适合使用PostgreSQL

• 速度:

如果大家需要读取操作的调整性，PostgreSQL并不合适。

• 设置简单性:

除非大家要求绝对的数据完整性、ACID合规或者复杂设计，否则PostgreSQL困难的设置流程并不适合选用。

• 复制:

除非大家愿意耗费时间、精力与资源处理这项工作，否则MySQL更适合数据库与系统管理经验较少的用户。

本文来源自DigitalOcean Community。英文原文：SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems By O.S. Tezer

翻译：diradw