三、MySsQL的结构

哎呀，我们来谈谈 MySQL。
它在数据库管理系统中是巨大的。
首先，你应该知道MySQL的结构就像一栋从头到脚的高楼大厦。

基础是数据库。
它是MySQL的基石，就像整个系统的核心。
MySQL Server 可以管理多个数据库。
每个数据库都是一个独立的单元，存储着不同的信息。

接下来，我们需要进入房间，看看里面有什么。
房间里的宝石是数据表。
一个数据库中可以有多个数据表，每个表都是一个用于存储数据的小盒子。
进入后，我们需要查看盒子中的内容。
框中的对象是字段，即表中的每一列。
每个字段就像一个小网格，用于存储特定类型的数据。
例如，学生表可能包含姓名、年龄和成绩等字段。

最后，我们需要查看每个网格中的内容。
网格中的对象是记录，即表中的每一行。
每条记录都是完整的信息，所有学生信息也是如此。

总之，MySQL的配置就像一层一层的建筑，从数据库到数据表，再到字段和记录，结构清晰，管理严格。
说起来，当时我并没有想到，现在想起来，还真是有趣。

access数据库的结构层次是什么

说白了，Access数据库的结构就像一座城市。
数据库覆盖整个城市，数据表代表城市的不同区域。
每个区域（表）都有自己的街道（记录），街道有不同的商店（字段）。
其实很简单。
我们先来说说最重要的事情。
数据库是数据的“数据库”。
一个数据库可以容纳多个数据表，就像一个城市可以有多个区域一样。

还有一点是，数据表是存储特定数据的“区域”。
每个表可以包含许多记录，就像一个地区有无数条街道一样。
例如，业务数据库可能有“客户表”、“订单表”、“产品表”等。
每个表存储特定类型的数据。

还有另一个关键细节。
记录是表中的行，代表一组完整的数据，例如有关客户的详细信息。
字段是定义数据类型和属性的表列，例如客户ID、姓名、性别等。

一开始我以为字段和记录可以随意组合，但后来发现这是错误的。
他们有固定的关系。
字段是记录的一部分。
一条记录由多个字段组成，这些字段一起描述一个实体。

等等，还有别的事。
表之间的关系是连接不同“区域”的桥梁。
例如，一个学生可能选择多门课程，需要一个“选课表”来建立多对多的关系。

最后提醒一下，当我们看到表之间的关系时，行话里我们实际上称之为雪崩效应。
事实上，前端的一点延迟会降低整个后端的性能。
因此，在设计数据库的时候，很多人都没有注意到这一点。
我认为值得一试。

一文详解数据血缘实体结构

我记得上次公司更新系统并将数据移至新数据库时，一群人正在屏幕周围观看日志。
一位朋友突然指着屏幕说：“哎，这些数据是怎么从Oracle到MySQL的呢？”当时，我觉得我真的需要了解数据是如何移动的。

数据库就像一个巨大的保险箱。
以前用文件柜，后来用网盘，现在用云服务器。
MySQL、Oracle等是不同的安全品牌。
迁移数据库其实是很累的。
例如，去年1 0月，我们将销售数据库迁移到Oracle。
整整花了三个星期，我们仍然每天凌晨两三点盯着同步日志。
坦率地说，数据库之间的关系取决于你如何从一个盒子中取出数据并将其放入另一个盒子中。
有时我使用ETL工具，有时我写脚本。
简而言之，我必须确保数据不会丢失。

电子表格更直观，就像 Excel 表格一样。
我们的项目中有一个表叫用户信息表，其中包含手机号码、出生日期、区号等字段。
表之间，例如用户信息表和订单表，您需要知道手机号码是如何关联的。
记得去年5 月份我做过一次举报，发现用户表中的手机号码与拨号表不符。
我确认字段类型错误。
用户表是一个字符串，订单表认为它是一个数字。
这个问题很常见。

最复杂的是字段。
去年1 2 月分析数据时，我发现其中一个字段来自CRM系统，经过三个流程，最后成为报表中的数据。
CRM中的出生日期是YYYY-MM-DD，但是在中间处理过程中变成了DD/MM/YYYY，最终报告中的格式是错误的。
田间育种意味着追求每一个小细节。
例如，不同系统的日期格式可能不同； Number类型，有的是整数，有的是小数；特殊字符（例如 ID 号的最后一位数字）可以用作扫描码。

我们使用的工具是自主研发的，每天自动管理血缘关系并生成报告。
但有时还是需要手动检查。
比如今年3 月份，我发现两个表的字段值不一样。
我手动检查过许久。
原来是初始系统修改了规则，最终系统没有同步。
工具可能无法捕获所有此类细节。

等等，还有别的事。
字段比例有一个取值范围的标准，就是一个字段可以取什么值。
例如性别只能是男或女，不能随便填写。
我们去年 9 月进行了审计，发现 Sales 表的值为“？”。
我们发现某个区域填写错误。
此类问题需要进行规则检查。
多字段关联就比较烦人了，比如冻结止付金额和状态。
如果金额为0则应该是正常的，如果金额大于0则应该被冻结。
这样的逻辑，写规则比写代码还要麻烦。

多表关联也会带来问题。
例如，多个表中的组织编号和产品代码必须保持一致。
去年1 2 月份，我们就开始了这个系统的建立。
只花了半个月的时间，因为两个系统中某个产品的代码不同。
有时您必须手动同步，例如当组织编号发生变化并且必须更改关联计划时。

数据沿袭既不简单也不复杂。
魔鬼在于细节。
工具可以解决大多数问题，但要真正有效，人们必须对其进行监控。
例如，我们去年每个季度进行的定期审计发现的问题比自动化工具更多。
等等，我突然想到，以后AI会自动检测血缘关系吗？人工智能还处于学习阶段，还不好。

如今，数据越来越多，系统也越来越复杂。
数据沿袭的重要性是不言而喻的。
但具体怎么做，每个人的方法都不同。
有的人靠工具，有的人靠劳动力，有的人靠系统。
不知道你们公司是怎么做的？