数据库分为哪三种

层次模型： 木结构。
父子关系。
插入和删除是有限的。
适用于简单的结构。

网格模型： 扩展级别。
多对多关系。
管理复杂。
冗余问题。

关系模型： 二维表。
行代表实例。
列代表属性。
最常用。
功能齐全。

对象模型： 与面向对象相结合。
关系基础知识。
处理复杂的结构。

关系型数据库和非关系型数据库之间的区别

2 02 2 年，我在某个城市做一个项目。
当时需求量特别大，数量也相当可观。
当时，我负责在关系型数据库和非关系型数据库之间进行选择。
这两个数据库都有自己的优点和缺点。

首先它是关系型数据库，类似于我们日常使用的Excel表格，结构清晰，易于理解。
SQL 语言的查询非常有用。
然而，有一个问题。
读写性能有点困难，尤其是面对大量数据时。
而且表结构是固定的，灵活性不够。

然后是非关系数据库。
它就像一个灵活的文件夹，您可以在其中放置任何您想要的格式的不同文件。
它具有优异的性能和强大的可扩展性。
但不支持SQL，学习成本较高，事务处理不如关系数据库严谨。

当时我很困惑。
您的项目需求巨大，关系数据库可能不够。
非关系数据库很灵活，但存在可靠性问题。
经过考虑项目的实际需求，我们最终选择了关系数据库。

也许我有偏见，但我认为关系数据库对于这个项目来说是更好的选择。
归根结底，数据安全性和一致性比灵活性更重要。

请简述数据库中网状模型的优缺点。

老实说，当我第一次接触网络模型时，我最直观的感受是它比关系模型更接近现实世界。
比如我参与的一个库存管理系统，供应商、产品、仓库之间复杂的层级关系是用网络模型来绘制的。
嗯，这真的很直观。
你看，一个供应商可以供应多个仓库，一个产品可以存放在多个仓库中。
这种层次化的“多对多”关系很容易用网络模型来处理。
不过，这东西的性能确实不错。
我们的系统可以查询特定批次的产品在哪些仓库，而且运行速度比关系模型快得多。

但是复杂性相当烦人。
我有一个同事负责维护这个系统。
后来他向我抱怨，每次有新人接手，他都要花两周时间才能弄清楚其中的结点和路径，说这“就像解决迷宫一样”。
最有问题的是DDL 和DML。
那时我们用COBOL。
每次我们想要添加一个新字段或更改关系时，代码都写得像天书一样。
我曾经帮他调试过。
看着嵌套的指针和路径表达式，我感到非常头晕，最终发现逗号使用不正确。

给我印象最深的是访问路径问题。
我记得有一次系统卡住了。
后来经过排查，发现某个特定的查询语句没有指定路径，所以干脆搜索了所有相关的表。
这使得开发人员在编写应用程序时像数据库管理员一样思考并预测用户将使用哪些路径。
该代码充满了“IF 路径 A THEN...ELSE 路径 B...”逻辑。
你觉得累吗？然而，在某些场景下，比如我们的库存系统，这个模型确实没有麻烦。
只要设计好路径，后续查询维护的成本其实很小。

数据我记得那是在2 0世纪9 0年代中后期左右。
网络模型在ERP系统中仍然有很多用例，但后来关系模型的标准化和易用性出现并慢慢被取代。
不过，现在想起来，我还是很怀念和同事们一起做那些嵌套循环查询的日子，但我的眼睛很快就会疲劳。