数据库不能直接存储多维数组，必须按语义拆解建模：数值矩阵用三列表（row_index、col_index、value），层级结构拆为多张外键关联表，临时数据可存JSON但违背关系模型本质。
多维数组本身不是数据库能直接存储的结构，数据库表天然就是二维的（行 × 列），所以“映射”不是把整个多维数组塞进一个字段，而是要根据语义把它**拆解、建模、规范化**到关系表中。
明确数据语义，决定表结构设计
不能一上来就想着“怎么存数组”，得先问：这个多维数组代表什么？是矩阵计算数据？是带坐标的网格信息？还是嵌套的业务对象（比如“每个班级有多个学生，每个学生有多门课成绩”）？不同语义对应不同建模方式：
- 如果是数值矩阵（如 5×4 的温度采样数据），适合用三列表：
row_index、col_index、value，主键可设为联合主键(row_index, col_index) - 如果是业务层级结构（如部门→员工→项目），应拆成多张关联表（
departments、employees、projects），用外键连接，而不是强行压成二维 - 如果只是临时传输或配置类数据（如前端传来的表格原始数据），且不需查询/索引/关联，可序列化为 JSON 存入 TEXT 或 JSON 类型字段，但这就脱离了“二维表映射”的本意
用 ORM 映射类到二维表（以 Python + SQLAlchemy 为例）
所谓“类映射到二维表”，本质是定义一个 Python 类，每个实例对应表中一行，每个属性对应一列。它不处理“多维数组整体”，而是让每行承载数组中的一个逻辑单元：
- 定义类时，
__tablename__指定表名，Column声明字段类型和约束 - 主键必须明确（如
id = Column(Integer, primary_key=True)），这是关系模型的基础 - 字符串字段建议指定长度（如
String(100)），避免 SQLite 默认的无界 TEXT 影响迁移一致性 - 执行
Base.metadata.create_all(engine)才真正建表，之前只是 Python 层定义
Java 二维数组存 MySQL 的典型做法
Java 的 int[][] arr = {{1,2,3},{4,5,6}} 在数据库里没有直接对应类型。常规做法是建一张明细表：
- 字段包括：
id（自增主键）、matrix_id（标识属于哪个数组，可选）、row_index、col_index、value - 插入时双重循环遍历数组，每元素生成一行记录；查询时按
row_index排序再分组还原 - 若需频繁按行列范围查询，可对
(row_index, col_index)建联合索引
避免常见误区
很多人想用一个字段存整个数组，比如写成 "[[1,2],[3,4]]" 字符串。这看似简单，但会带来严重问题：
- 无法用 SQL 直接筛选某行某列的值（得靠应用层解析，丧失数据库计算能力）
- 没法加索引，大数据量时查询极慢
- 违反第一范式，难以维护、扩展和关联其他表
- 不同语言/版本对序列化格式兼容性差（如 Python pickle 和 Java 序列化互不识别）
