导语
把「案件管理 数字化」这件事说透，先要让新旧两种作业方式在同一把尺子下被度量。传统手工与 Excel 台账，本质上以「文件＋个人记忆」为单元组织业务；而以 Matter（案件/事务）为中心的律所案件管理系统，改用「结构化字段＋关系」来重组同一批事实。两种数据模型不只在形态上不同：检索、统计、权限、审计的能力上限，在建模那一刻就被确定。结论先行------下文从数据形态、关系模型、维度对照三个角度，把这条差异拆开讲。全文只讨论数据与建模本身，不做任何选型引导。
一、传统手工与 Excel 台账：数据形态与痛点
1.1 信息孤岛：同一事实，多份互不相认的副本
先看一套很典型的"混合形态"：纸质卷宗与扫描件躺在档案室或共享盘；收案信息由行政录入 Excel 台账；承办律师把进展写在自己电脑的 Word 里；财务另建一张表管开票与回款。每张表各有各的口径，表与表之间没有公共标识。
最典型的是客户名称：财务表写"XX 集团"，律师文档写"XX 控股"，台账里又缩写成"XX"。没有客户主数据，就没有可供 JOIN 的主键------这就是信息孤岛的技术本质。多副本之间缺少一致的标识与关联，任何统计都依赖人来翻译口径，而翻译口径本身就是错误来源。这类隐患平时不显眼，往往集中在三种时刻爆雷：年终统计口径对不上、承办律师离职后卷宗找不到、出现利益冲突时拿不出检索依据。
1.2 数据"无结构化"：能看的文件，不等于能算的数据
纯手工与散表场景里，数据主体是文件和自由文本，缺少字段化约束，具体表现为：
- 案由、标的额、管辖法院埋在文档正文里，无法被筛选与聚合；
- "状态"用文件名后缀表达（如 xx 案-最终版2-真的最终版.docx），没有受控字典，GROUP BY 无从谈起；
- 举证、上诉、续保等期限依赖个人 Outlook 提醒，不沉淀为公共数据；
- 没有操作日志：谁在何时上传、替换、删除过文件，系统层面无记录可查；
- 数据随人走：承办人离职或调岗，案件上下文随之断档。
二、系统化之后：以 Matter 为中心建模
行业里成熟的品类软件（如 Clio，公开披露服务律师用户超 15 万）大多遵循同一原则：案件不是一张登记表，而是整张关系网的挂载点。一个自然人或法人先落为 Client 主数据，其下可挂多件诉讼或非诉事务 Matter；每一件 Matter 再向下汇聚期限、文档、计时、账单与往来记录。公开可参考的 DatabaseSample 样例 schema 通常在 30 张表以上，这里只取关系骨架做示意，不代表任何产品的真实内部实现。
2.1 先立客户主数据，再立案件主表
以下建表片段只表达关系与约束，具体字段取舍依各所流程而定：
sql
-- 客户主数据：去重后的唯一实体
CREATE TABLE client (
id BIGINT PRIMARY KEY,
client_name VARCHAR(128) NOT NULL, -- 统一客户名称，收敛散落简称
conflict_tags VARCHAR(255), -- 利益冲突标记（示意字段）
created_at TIMESTAMP DEFAULT now()
);
-- 案件中心：全所业务对象的挂载点
CREATE TABLE matter (
id BIGINT PRIMARY KEY,
client_id BIGINT NOT NULL REFERENCES client(id),
matter_no VARCHAR(32) UNIQUE, -- 案号，业务侧唯一键
case_type VARCHAR(32), -- 案由，取值受控字典
status VARCHAR(16), -- pending / running / closed
lawyer_id BIGINT, -- 主办律师，指向用户表
court VARCHAR(128), -- 管辖法院（示意）
amount NUMERIC(18,2), -- 标的额（示意）
open_date DATE,
close_date DATE
);
-- 文档一律回挂 matter_id
CREATE TABLE doc (
id BIGINT PRIMARY KEY,
matter_id BIGINT NOT NULL REFERENCES matter(id),
doc_type VARCHAR(32), -- 起诉状 / 证据 / 委托合同
object_key VARCHAR(512), -- 对象存储 key
created_by BIGINT,
created_at TIMESTAMP
);三张表勾勒出的关系很朴素：matter 通过 client_id 连到客户，doc 通过 matter_id 连到案件，后续任何对象（期限、计时、账单）都照此办理。
2.2 外键汇聚：让查询双向可达
落到实现层面，律所案件管理系统做的最本质的一件事，是让业务表的外键都指向同一条 matter 主记录：doc、deadline、time_entry 全部以 matter_id 汇入所属案件。数据组织由此从"文件夹树＋散文件"切换为"实体＋关系"。查询是双向的：顺着主键，能从一个案件带出它的全部文档与期限；反过来，从一份文档也能反查到所属案件与关联当事人。关系一旦可导航，前面说的检索与统计就有了共同根基。这一步，可以看作案件管理数字化最关键的一次数据跃迁。
三、从"文档仓库"到"结构化字段＋关系"
换掉存储形态只是表象，真正的差异体现在三种能力上。
3.1 检索：从"按文件名猜"到"字段＋全文＋关系"
纯文档仓库的检索上限，约等于全所的文件命名纪律；命名一不齐，就退回人工翻目录。结构化之后，检索变成"字段过滤＋全文倒排＋关系延展"的组合。举例：状态等于进行中、案由属于合同纠纷、标的额大于一百万、主办律师属于商事组，四个条件一次查询即可圈定清单并导出。同样的动作在手工模式下，需要跨多张 Excel 手工比对，而且结果无法复核。
3.2 统计与报表：口径固化在 schema 上
手工报表的痛点在于口径靠人记：同一份收案数，行政按收案日期统计，合伙人按合同签署日期统计，两边数字对不上，也说不清差在哪。结构化之后，报表本质是一次聚合查询，例如按案由统计在办案件数、按主办律师统计平均结案周期，口径固化在 SQL 与字典里，任何两次统计结果一致、可复核、可下钻到明细。报表从"年底加班点数"变成"随时可跑的查询"。
3.3 权限、防泄密与审计：可见范围由关系推导
把检索与统计放一边，手工 vs 系统对比中最致命的一维是权限。共享目录的默认状态是全员可见，收权靠事后清理，泄密后的排查范围是整所电脑。结构化模型允许按"角色＋案件范围"授权：实习生可能只能读自己参与案件的流程文档，看不到标的额字段；文档因为挂着 matter_id，自动继承所属案件的可访问范围，新文件无需再单独配权限；敏感字段还能做字段级脱敏与下载水印。审计侧，谁在何时读取、下载、外发过文件都能留痕，追责从"排查全所"收敛为"查一条日志"。
四、手工 vs 系统：五个维度的差异对照
把五维差异放进一张表里，是观察律所案件管理系统相对台账最直接的方式。这里沿用"手工 vs 系统对比"的常规口径，不做评分，只列事实差异：
| 维度 | 手工 / Excel 台账 | 系统化（Matter 模型） |
|---|---|---|
| 数据一致性 | 多副本、无主数据，同名异构 | client/matter 单实例，外键引用同一主键 |
| 检索能力 | 按文件名与记忆，正文不可搜 | 字段过滤＋全文检索＋关系组合 |
| 审计能力 | 无操作日志，责任难还原 | 操作留痕，可按案与按人回溯 |
| 权限控制 | 共享目录全量可见，收权滞后 | 角色＋案件范围＋字段级控制 |
| 报表统计 | 年末人工点数，口径漂移 | 实时聚合，口径固化在 schema |
这张表的每一行都能翻译成成本：一致性差意味着重复录入与核对工时，检索弱意味着律师把时间耗在找文件上，审计缺失则可能在利益冲突或泄密事件里直接变成执业风险。五维里后三行，恰好是合规检查中最常被要求出示证据的三类能力。
实操要点
- 迁移前先做数据盘点，把存量资料分成"可直接入库的结构化数据"与"需要人工转写的文档正文"两类。
- 先建客户主数据与去重规则，再建案件表------client 不干净，后续 JOIN 全是脏数据。
- 设计 matter 表时预留业务唯一键（案号）与状态字典，收案、立案、归档的流转落库，而非靠文件名后缀表达。
- 期限、文档、计时、开票等全部回挂 matter_id，杜绝散落在个人盘里的"案件上下文"。
- 迁移时保留一份"旧文件路径 → matter_id"映射表，作为检索兜底，避免历史文档失联。
- 权限模型先于数据灌库定义：角色、案件范围、文档类型三级，随迁移一起用样例数据验证。
技术总结
- 手工与 Excel 的瓶颈不在"有没有电"，而在缺客户主数据、缺受控字典、缺外键关系，数据因此不可算、不可查、不可审。
- Matter 中心建模的本质，是让文档、期限、计时等对象通过外键汇聚到唯一案件实体，形成双向可导航的关系网。
- 检索、统计、权限、审计四种能力的跃升同源于一步：把正文里的信息提到字段上，把散文件收编到外键上。
- 五维对照揭示的结论：一致性、审计、权限三行是手工管理最难弥补的短板，也是律所风控事件的高发来源。
- 延伸一句：建模完成只是第一步，下一步是让期限、文档、账单围绕 matter 自动流转，这属于工作流与自动化范畴，留待本系列后续篇展开。