数字心理沙盘的动作记录包含时间、坐标、沙具类型等字段，是常见的半结构化数据。MongoDB适合用文档组织这些记录，MySQL也有原生JSON及相应索引能力，选型应结合查询、写入和运维要求。
针对此类非结构化数据的存储需求，橙星云研发团队在架构选型阶段采用了 MongoDB。以下是我们在实际业务中应用文档型数据库的一些技术实践。
BSON文档适合怎样的数据
MongoDB以BSON文档保存数据，同一集合可以包含不同字段与嵌套结构。但灵活结构仍需要应用验证或集合校验，例如时间单位、坐标类型和必填标识要一致，避免分析时混用。
下面是说明数据结构的虚构记录，字段沿用常见沙盘事件形式：
{
"student_id": 9932,
"action_type": "DRAG",
"item": { "type": "TIGER", "color": "ORANGE" },
"coordinates": { "x": 12.5, "y": 9.2, "z": 0.0 },
"timestamp": 1721029302910
}mongoTemplate.insert(trajectory)是应用层写入方式之一，实际持久化确认还受映射、写关注和部署配置影响，不能仅凭一次方法调用就保证磁盘写入与故障恢复。
MySQL新增JSON键不必新增表列
MySQL 8.4官方文档介绍原生JSON类型与二进制访问，以及从JSON提取标量的生成列索引、数组多值索引。因此，增加一个沙具属性可以修改JSON内容，不必每次执行ALTER TABLE；按JSON查询也不必然全表扫描。
若现有业务依赖关系约束和跨表事务，可以评估在关系数据库中保留JSON；若文档访问和结构变化更符合业务，可以评估MongoDB。团队维护经验、备份恢复、数据治理和总体成本也影响选择。
嵌套字段索引要与查询对应
MongoDB官方索引文档支持用点路径索引内层字段。在我们的数据库初始化脚本中，会针对高频查询的内层属性建立针对性索引：
db.sandplay_trajectories.createIndex({ "item.type": 1 });
db.sandplay_trajectories.find({ "item.type": "TIGER" })
.limit(100).explain("executionStats");若实际请求还限定学校、批次和时间，需要考虑相应复合索引与排序。只建item.type单字段索引，不代表包含这些条件的全部查询都会高效，也不替代学校或租户的数据访问鉴权。
explain执行统计可帮助检查使用的计划、扫描索引项、扫描文档数与返回数。还要测实际返回量、冷暖缓存、并发和写入代价。命中索引的查找成本不能直接推出完整请求在千万条数据下必然毫秒完成。
针对数据持续增长的沙盘项目，可以把索引优化与容量验证纳入交付：根据实际查询筛选字段设计索引，用接近目标规模的数据比较优化前后的扫描量和耗时，再确定可验收的性能目标。这样能把“查询更快”落实成可复核的改进，同时保留初始化建立索引的工程实践；毫秒级响应若要作为项目承诺，应先明确硬件、数据量、并发和返回条数，并通过相应测试。
沙具类型是交互记录，不是独立的心理诊断证据。技术设计先保证数据含义、权限和查询可验证，再为后续有依据的分析提供资料。