2. 数据模型与存储：关系型数据库与非关系型数据库在材料数据中的应用对比
做材料数据库，选型是第一道坎。
我见过不少团队，一上来就拍脑袋选MySQL，结果存材料图谱数据时把自己折腾得够呛。也见过迷信MongoDB的，存个成分表搞得查询效率惨不忍睹。说白了，没有银弹，只有合适不合适。
这一章，我就结合自己踩过的坑，聊聊关系型和非关系型数据库在材料数据场景下的真实表现。
2.1 关系型数据库：MySQL与SQLite
关系型数据库的核心是「表」和「关系」。你想想看，材料成分、工艺参数、性能指标，这些天然就是结构化的表格数据。用关系型数据库来存，逻辑上就很顺。
2.1.1 MySQL：适合团队协作与高并发
MySQL是我个人最常用的关系型数据库。在材料数据库场景下，它特别适合存那些「字段固定、查询频繁」的数据。
典型场景：
- 材料成分表（元素、含量、杂质上限）
- 力学性能表（抗拉强度、屈服强度、延伸率）
- 工艺参数表（温度、压力、保温时间）
核心优势：
- 事务支持：多用户同时写入时保证数据一致性
- 成熟生态：ORM框架、可视化工具一应俱全
- 查询优化：复杂JOIN查询性能稳定
我在项目中遇到过一个问题：材料性能数据经常需要做范围查询（比如找抗拉强度在500-800MPa之间的材料）。MySQL的B+树索引对这种查询支持得非常好，加个复合索引，毫秒级返回。
我的建议：材料成分表一定要建联合索引。比如(元素, 含量下限, 含量上限)，这样查「含Cr 10%-15%的不锈钢」时，索引直接命中，不用全表扫描。
2.1.2 SQLite：轻量级本地存储
SQLite是我做原型验证时的首选。它不需要安装服务，一个文件就是一个数据库。对于单机版的材料数据管理工具，或者嵌入式设备上的材料数据采集，SQLite简直是神器。
适用场景：
- 实验室单机数据采集系统
- 材料数据库的离线备份格式
- 移动端材料查询App
注意：SQLite不支持并发写入。如果你有多个用户同时写数据，别用它。我曾经在一个小团队里图省事用了SQLite，结果两个人同时录入数据时直接报错——嗯，从那以后我记住了这个坑。
2.2 非关系型数据库：MongoDB
非关系型数据库，说白了就是「不拘一格存数据」。材料数据里有很多「半结构化」甚至「非结构化」的内容，比如材料显微图像、EBSD数据、相变过程的时序数据。这些用关系型数据库存，你得先设计一堆表，然后写复杂的JOIN，累不累？
2.2.1 MongoDB的文档模型
MongoDB存的是JSON-like的文档。每个文档就是一个完整的材料记录，字段可以不一样。这太适合材料数据了——你想想看，铝合金和陶瓷的性能字段能一样吗？用关系型数据库你得搞一堆NULL字段，用MongoDB直接各存各的。
典型场景：
- 材料图谱数据（节点、边、属性不固定）
- 实验过程日志（字段随实验步骤动态变化）
- 材料文献元数据（摘要、关键词、引用关系）
核心优势：
- Schema-less：字段可以随时增减，不用跑迁移脚本
- 嵌套文档：一个材料的所有信息可以存在一个文档里
- 水平扩展：数据量大时直接加机器
2.2.2 实际案例：材料图谱存储
我之前做过一个材料知识图谱项目，存的是「材料-工艺-性能」之间的关联关系。用MySQL的话，至少需要三张表加两张关联表，查询时四表JOIN。用MongoDB，一个文档搞定：
{
"_id": "mat_001",
"name": "TC4钛合金",
"composition": {
"Ti": "余量",
"Al": "5.5-6.75%",
"V": "3.5-4.5%"
},
"process": [
{"type": "热处理", "temp": "950°C", "time": "1h"},
{"type": "锻造", "temp": "1050°C", "ratio": "3:1"}
],
"properties": {
"tensile_strength": "950MPa",
"yield_strength": "880MPa",
"elongation": "10%"
},
"relations": [
{"target": "proc_001", "type": "经过处理"},
{"target": "prop_001", "type": "具有性能"}
]
}你看，一个文档就把材料的所有信息包进去了。查询时直接按材料ID取文档，一次IO搞定，不用JOIN。
避坑指南：MongoDB虽然灵活，但别滥用嵌套。我见过有人把实验数据全部嵌套在一个文档里，结果一个文档几十MB，查询和更新都慢得要命。合理的做法是：频繁查询的字段放顶层，大块数据（如图像二进制）单独存集合。
2.3 对比总结：怎么选？
我个人的经验是：
| 维度 | MySQL/SQLite | MongoDB |
|---|---|---|
| 数据结构 | 固定字段，强约束 | 灵活字段，弱约束 |
| 查询类型 | 复杂关联查询 | 单文档查询、聚合管道 |
| 数据一致性 | 强一致性（ACID） | 最终一致性 |
| 扩展方式 | 垂直扩展为主 | 水平扩展为主 |
| 典型材料数据 | 成分表、性能表、工艺参数 | 图谱数据、实验日志、文献元数据 |
我的选择原则：
- 如果数据字段固定、查询模式明确、需要事务支持 → 选MySQL
- 如果只是单机用、数据量不大、图省事 → 选SQLite
- 如果数据结构多变、字段不固定、需要快速迭代 → 选MongoDB
重要提醒：别想着一个数据库打天下。我现在的做法是「混合存储」——结构化核心数据放MySQL，非结构化或半结构化数据放MongoDB。两个数据库通过材料ID关联，各取所长。
2.4 知识体系总览
下面这张图，是我对本章核心逻辑的梳理。你可以看到，关系型和非关系型并不是对立关系，而是互补关系。关键是根据数据特征选对工具。
这张图其实就表达了一个意思：别纠结于「哪个数据库更好」，而是问自己「我的数据长什么样」。数据是规整的表格？上关系型。数据是灵活的文档？上非关系型。就这么简单。
最后说一句：选型不是一锤子买卖。项目初期用SQLite快速验证，数据量上来后迁移到MySQL，发现需要存图谱数据再加MongoDB——这都是正常的演进路径。别想着一步到位，先跑起来再说。
公众号:蓝海资料掘金营，微信deep3321