数据库的类型有哪些？

层次数据库，这个东西最早在2 0世纪6 0年代就出来了，IBM的IMS就是一个典型的例子。
看它的结构，它就像一棵倒立的树。
最上面有一个根节点，下面一层层划分，就像公司的组织结构一样。
总部下设分公司，分公司下设部门。
这种树结构就很合适了。
但如果要跨层查看数据，比如同时查看一个人属于哪个项目组，那就很烦人了。
你必须知道找到它的确切路径，这使用起来确实不灵活。
当时，十几八年的时间，这种模式已经相当主流了。

网格数据库比分层数据库稍微先进一些，自 2 0 世纪 7 0 年代以来一直在使用。
它允许多个节点作为根，单个节点可以连接到多个父节点。
它看起来像一个传输网络图，节点之间有随机路由。
理论上，它们可以表示特别复杂的关系，但在实践中，人们仍然习惯于简单的一对多关系的堆叠，这使得遇到多对多关系时变得非常复杂。
在那个时代，维护网络数据库需要专业程序员，这是昂贵的。
后来，它被关系数据库取代。

关系数据库现在无处不在。
它在 2 0 世纪 8 0 年代开始非常流行，并且从未失宠。
核心是一张表格，就像Excel一样。
我之前的公司使用的是 Oracle，这是金融专业人士最喜欢的。
能够承受高并发，同时处理数万笔交易没有任何问题。
微软的SQL Server也不错。
它被中小型组织广泛使用，并且与 Office 配合良好。
还有MySQL，现在很受互联网开发者的欢迎。
它是免费的并且运行速度很快。
你只要安装它就可以创建个人网站、小程序等。
更不用说Access了，现在几乎没有人使用它。
它是微软当时和Office一起带来的，用来制作小笔记本来记录东西。
像FoxPro和Sybase这样的老品牌可能还会被公司退休的程序员提及几次，但年轻人基本上已经不再接触它们了。

要运行这些数据库，一切都基于 SQL，即结构化查询语言。
ANSI 在 2 0 世纪 7 0 年代末首次制定了标准，表示应该有统一的语法。
现在，恨不管什么数据库，只要写SELECT、INSERT或者UPDATE，基本都能运行。
刚学SQL的时候，在Oracle和MySQL上写过数据，发现没有太大区别，于是一两天就开始了。
然而，市场上9 9 %的数据库都是关系型数据库，所以别无选择。

按收录信息内容的类型可将数据库如何划分

顺便说一句，当谈到文档数据库和数值数据库时，我已经参与问答论坛很多年了，这两者确实有点令人困惑。
这是因为虽然它们都是数据库，但它们服务于完全不同的领域和目的。

首先，我们来谈谈书目数据库。
它就像一个电子版的图书馆，包含各种文档和资料。
我记得有一次帮一位做历史研究的同学查资料，他就用了这个数据库。
那是2 01 5 年了，学校图书馆的文献数据库已经非常丰富了。
它不仅有书目数据库，而且还允许直接全文搜索。
我帮他找了好久，终于在中国知网（CNKI）找到了他想要的古文献。

对于数值数据库来说，这类似于科研人员的“数据仓库”。
我有一个从事生物统计工作的朋友，他经常使用数值数据库。
他曾经告诉我，他使用SPSS（统计软件）来分析实验数据，但这些数据是从数值数据库中提取的。
我记得他说他用的数据库叫国家科技统计数据库，里面有各种科研数据、统计教育数据、实验数据，甚至临床试验数据。
这是一个大数据的宝库。

说实话，这两类数据库各有各的特点。
文档数据库侧重于收集和检索书目材料，而数值数据库侧重于数据存储和分析。
这可能有点极端，但我认为书目数据库对于一般用户来说更实用，因为没有人不想查信息或看论文。
数值数据库只是人们进行科学研究的必需品。

当时我不明白为什么需要对两类数据库进行如此明确的区分。
也许因为他们服务的领域不同，他们的数据库的结构和内容也会不同。
但最重要的是，这两类数据库是科学研究和学术界的重要工具。

数据库有哪些类型?

不幸的是，刚进入这个行业时，数据库让我很头疼。
想一想，以前做项目的时候，选择并不多。
本质上，关系数据库是唯一的选择。
当时我们公司用的是Oracle。
当时Oracle的价格非常昂贵，只有财力雄厚的大公司才能买得起。
我记得有一年，我们正在研究金融系统。
数据量不大但要求高，不能出错。
使用Oracle，我们在事务控制和数据一致性问题上苦苦挣扎了一段时间，最终解决了它们。
当时我感觉关系型数据库稳定可靠。

后来，互联网迅速发展，数据量爆发式增长。
有时关系数据库无法满足他们的需求。
这时，非关系型数据库逐渐流行起来。
我们的团队从事一个电子商务项目，该项目拥有大量用户和更令人生畏的数据量。
当时我们使用的是非关系型数据库MongoDB。
想想看，用户行为数据是非结构化的，使用 MongoDB 可以在几分钟内处理完毕。
此外，该项目要求系统能够快速扩展以处理高峰流量。
使用 MongoDB 在几分钟内设置集群并扩展容量。
这种性能和可扩展性是关系数据库无法比拟的。
但是，有时候我们还是要使用关系型数据库，比如对于订单数据，那么我们就必须使用关系型数据库。
数据一致性太重要了。

所以你说哪个数据库更好要看具体情况。
关系型数据库适用于数据结构固定、数据一致性要求较高的情况。
非关系型数据库适合数据量大、对性能和可扩展性要求较高的情况。
这个必须根据实际情况来选择，不能一概而论。