简介：《致远OA V8.1 数据字典》是一份面向致远OA开发、实施、运维及二次开发人员的数据库结构速查文档，覆盖表结构、字段类型、约束条件与注释说明，主要用于解决表字段含义不清、SQL编写缺少依据、系统升级排查困难等问题。压缩包共1个PDF文件，约2.2MB，便于本地检索和随查随用。文档以ADDRESSBOOK、ADDRESSBOOK_MEMBER等表为例，逐项列出字段名称、数据类型、是否强制及中文注释，涵盖主键、人员ID、创建与更新时间，以及文本、数字、日期、枚举、选人、选部门、选岗位等扩展字段，并补充用户名称、单位、部门、岗位、联系方式等联系人信息字段，方便核对数据完整性。已有2611人学习，适合在二次开发、接口对接、数据查询和系统维护升级时对照使用，帮助读者快速定位字段含义、理解表间关系、排查数据异常并评估结构变更影响。
1. 数据字典为什么比源码更快说清一套 OA 的整体结构
接手一套跑了多年的 OA，最快的上手方式不是读源码，而是把 V8.1 数据字典摊开，看字段类型和长度。代码会误导你：它会重构、会分层封装、会把 SQL 拼在字符串里；表结构不会。它是十来年业务沉淀留下来的痕迹，能随便改表的人不多，所以每一列的长度、每一个状态位的取值，背后都有一次具体的业务演进。这份字典里最直观的一处是 ADDRESSBOOK 表：主键、人员 ID、两个时间戳之后，接上了 70 个 EXT_ATTR 扩展字段。这个数字本身就说明了架构选择——业务变化的速度远快于建表的速度。读数据字典要回答三类问题：这条数据从哪来（字段类型、长度、是否强制）、谁能看见（范围表）、历史怎么保留（状态位与归档表）。带着「为什么这么设计」去看字段类型，比背字段名有用得多。
2. 70 个 EXT_ATTR：宽表为什么代替了 EAV
2.1 七段式列族：类型在段位里，不在元数据里
把 ADDRESSBOOK 的扩展字段按顺序拆开，会看到一条非常整齐的分段：EXT_ATTR_1 到 10 是 VARCHAR(1024) 文本，11 到 20 是 DECIMAL(19,4) 数字，21 到 30 是 DATETIME 日期，31 到 40 是 VARCHAR(50) 枚举，41 到 50、51 到 60、61 到 70 同样是 VARCHAR(50)，但语义分别是选人、选部门、选岗位。这不是随便排的，而是「列族」思路：把同一类型的扩展位集中放在连续段位里，应用层只要知道序号落在哪一段，就完全确定该怎么解析、怎么校验、怎么渲染表单。
| 段位 | 类型 | 数量 | 典型用途 | 容易踩的点 |
|---|---|---|---|---|
| 1-10 | VARCHAR(1024) | 10 | 备注、拼接串、JSON 摘要 | 长度够但没约束，脏数据多 |
| 11-20 | DECIMAL(19,4) | 10 | 金额、工时、评分 | 精度够，但业务单位靠约定 |
| 21-30 | DATETIME | 10 | 时间点、到期日 | 无时区，跨区部署要统一 |
| 31-40 | VARCHAR(50) | 10 | 枚举 code | 存 code 不存 label，别直接展示 |
| 41-50 | VARCHAR(50) | 10 | 人员实体 ID | 多选会截断，只能放一个 ID |
| 51-60 | VARCHAR(50) | 10 | 部门实体 ID | 同上，且部门会合并撤销 |
| 61-70 | VARCHAR(50) | 10 | 岗位实体 ID | 同上 |
为什么不走 EAV（一张 attr_name / attr_value 竖表）？因为 EAV 每读一条业务记录都要 join 一次扩展表，再 pivot 成行；一个列表页十几个扩展字段就是十几次 join 或者一次大 union，SQL 优化器很难优化出执行计划。宽表把这些成本全部转移到了写入和存储上，而扩展字段的读频率远高于写频率。DECIMAL(19,4) 的选择也有讲究：19 位总长、4 位小数，整数部分能放 15 位，足够覆盖金额和工时两类场景，又不需要在应用层做浮点转定点。
2.2 语义在其他位置：数据库只存字节，元数据在配置里
这份字典读起来最别扭的地方是：字段名全是 EXT_ATTR_N，业务含义一个都没写。因为扩展字段的「显示名、是否必填、下拉选项、默认值、在表单第几行」这些信息不在数据库里，而在扩展字段定义和表单配置里。数据库只保证「存得下、类型对」，语义完全由上层解释。这就导致一个很现实的问题：光看字典查不出某个扩展字段装的是什么，只能靠段位猜大类，再靠数据分布反推。
-- 反查某个扩展位到底有没有在用：非空行数 + 取值样例 SELECT COUNT(*) AS total, COUNT(EXT_ATTR_11) AS not_null_cnt, -- 数字段位，统计非空 MIN(EXT_ATTR_11) AS min_val, MAX(EXT_ATTR_11) AS max_val FROM ADDRESSBOOK WHERE TYPE = '1'; -- 按通讯录类型缩小范围 -- 引用型段位（41-50 选人）要看 ID 的分布，判断是不是多选拼接 SELECT EXT_ATTR_41, COUNT(*) AS cnt FROM ADDRESSBOOK WHERE EXT_ATTR_41 IS NOT NULL AND EXT_ATTR_41 <> '' GROUP BY EXT_ATTR_41 ORDER BY cnt DESC LIMIT 20;第一段 SQL 判断「这个位有没有人用、值域大概在哪」，第二段判断「这个位存的是单个 ID 还是拼接串」。如果结果里出现逗号分隔的长串，基本可以确认是多人多选硬塞进 VARCHAR(50)，长度一超就被截断——这是这类设计最常见的坑，后面第 5 章会单独说。枚举段位还有个约定：存的是 code 不是显示名，所以直接 SELECT 出来给人看会得到一串数字字母，必须过一遍枚举字典。
2.3 按段位分派的读写代码
扩展字段的读写难点不在 SQL，而在类型转换集中在一处还是散落各处。常见的实现思路是把段位表做成一个常量映射，所有读写都走同一个入口，禁止业务代码里直接row["EXT_ATTR_11"]。
# 段位 -> (解析类型, 附加参数) 的唯一事实来源 EXT_SEGMENTS = [ (1, 10, "text", None), # VARCHAR(1024) (11, 20, "decimal", (19, 4)), # DECIMAL(19,4) (21, 30, "datetime", None), # DATETIME (31, 40, "enum", 50), # 枚举 code (41, 50, "member", 50), # 人员实体 ID (51, 60, "dept", 50), # 部门实体 ID (61, 70, "post", 50), # 岗位实体 ID ] def attr_kind(index: int): """根据 EXT_ATTR_N 的 N 反推语义类型，越界直接报错而不是静默兜底""" for low, high, kind, extra in EXT_SEGMENTS: if low <= index <= high: return kind, extra raise ValueError(f"EXT_ATTR_{index} 不在预留段位内") def read_attr(row: dict, index: int): """统一读入口：NULL 统一返回 None，空串也归一成 None，避免下游两套判断""" kind, extra = attr_kind(index) raw = row.get(f"EXT_ATTR_{index}") if raw is None or raw == "": return None if kind == "decimal": return round(float(raw), extra[1]) # 定点转浮点只在这一层发生 if kind == "datetime": return raw # 交给上层格式化，别在这里拼字符串 return raw # text / enum / 引用型都原样返回 ID 或 code这段代码的关键不是转换本身，而是「越界报错」。段位之外的 N 一定是脏数据或者历史遗留，静默兜底会让问题延后到报表层才暴露。另外空串归一成 None 很重要：数据库里 NULL 和空串混用是常态，如果不在入口统一，每个查询条件都要写IS NOT NULL AND <> ''两遍。
2.4 加列的代价：宽表不是没有成本的
70 个扩展位加上业务字段，ADDRESSBOOK 的列数已经接近三位数。很多人以为宽表的主要代价是存储，其实不是——VARCHAR 是变长类型，NULL 只占 NULL 位图里的一个 bit，数据区不分配空间；真正的代价有三个。第一是 DDL：早期版本给大表加列会锁表重建，即使后来的版本支持 instant add column，也有「新列必须加在最后」之类的限制，所以扩展位只能一次性预留够，事后追加会破坏段位约定。第二是行溢出：一旦有多个 VARCHAR(1024) 真的写满，行长度超过页的一半就会触发溢出页，随机读会多一次 IO。第三是可维护性：任何一次全表SELECT *都会把 70 个空列捞回来，网络和反序列化开销白白浪费。常见的做法是查询层强制列白名单，禁止SELECT *。
3. 多态引用与范围表：为什么这套表结构里几乎没有外键
3.1 一个 ENTITY_ID 三张表用：多态引用的三种写法
组织模型里的人员、部门、单位、岗位、职务级别分散在多张表里，任何一个业务对象要引用「某个组织实体」，都没法在数据库层建外键。这套字典里给出了三种风格不统一的解法，正好能看出演进的痕迹。
| 表 | 类型字段 | 类型字段形态 | 取值含义 |
|---|---|---|---|
| ADDRESSBOOK_SET_SCOPE | USER_TYPE | VARCHAR(50) | 组织模型实体类型，字符串形式 |
| AGENT_SCOPE | ENTITY_TYPE | VARCHAR(50) | ACCOUNT、DEPARTMENT 等字符串 |
| ATTENDANCE_AUTH_ENTITY | ENTITY_TYPE | SMALLINT | 3 人员、1 部门、0 单位 |
同一件事三种表达：字符串型更可读、加新类型不用改表，但拼错一个字符就变成孤儿数据；数字型更省空间、能建联合索引，但语义要靠文档。这些表全部没有外键约束，级联删除、引用完整性都靠应用层。这是刻意的取舍：OA 的组织架构调整非常频繁（部门合并、人员调岗、单位拆分），如果挂了外键，一次组织调整会被数据库的约束检查卡住，甚至出现「删不掉旧部门因为历史单据还引用着」的死局。
代价是脏数据不可避免。所以字典里出现了几组专门的记录表：AI_ORG_CHANGE_RECORD 记 OLD_ID / OLD_VALUE / NEW_ID / NEW_VALUE，ORG_TYPE 区分部门、岗位、职务级别；AI_ORG_MEMBER_CHANGE 记 MEMBER_ID 加上旧单位、新单位、旧部门、新部门、旧岗位、新岗位、旧职务级别、新职务级别。这两张表本质上是组织调整的变更记录：调整完成后，如果报表数据对不上，可以顺着这两张表倒推是哪一次调整、哪个字段从什么变成了什么。
3.2 范围表模式：SET 管规则，SCOPE 管对象
通讯录的可见性设计是这套字典里最值得学的一块。ADDRESSBOOK_SET 存的是「设置本身」：VIEW_SCOPE 表示查看范围策略、KEY_INFO 和 KEY_INFO_TYPE 表示关键信息展示（1 手机号加职务级别、2 只要手机号、3 只要职务级别）、EXPORT_PRINT 控制导出打印、DISPLAY_COLUMN 是 VARCHAR(1024) 的显示列清单、EXTERNAL_SCOPE 控制编外人员（1 按工作范围显示、2 全部隐藏）、M3_SET 和 ZX_SET 分别是移动端和另一个客户端的独立显示设置、DEPARTMENT_INFO_ORDER 控制部门与人员谁排前面。一张表把「谁能看什么、看到哪些列、能不能导出」全部收进去。
ADDRESSBOOK_SET_SCOPE 才是范围明细：ADDRESSBOOK_SET_ID 指回设置，ADDRESSBOOK_SET_TYPE 用 1/2/3 区分这条明细属于查看范围、关键信息还是导出打印权限，USER_ID 加 USER_TYPE 指向具体的组织实体。也就是说，同一张 scope 表被三类设置复用，靠一个类型字段分流。
-- 判断「我」能不能看到某人的通讯录条目 -- 第一步：找到本单位的通讯录设置 WITH cfg AS ( SELECT ID FROM ADDRESSBOOK_SET WHERE ACCOUNT_ID = :accountId ), -- 第二步：只取查看范围那一类明细，TYPE 漏了就会把导出权限当成可见范围 scope AS ( SELECT s.USER_ID, s.USER_TYPE FROM ADDRESSBOOK_SET_SCOPE s JOIN cfg ON cfg.ID = s.ADDRESSBOOK_SET_ID WHERE s.ADDRESSBOOK_SET_TYPE = 1 ) SELECT 1 FROM scope WHERE (USER_TYPE = 'MEMBER' AND USER_ID = :myMemberId) OR (USER_TYPE = 'DEPARTMENT' AND USER_ID IN (:myDeptIds)) OR (USER_TYPE = 'ACCOUNT' AND USER_ID = :accountId) LIMIT 1;这段 SQL 的写法直接决定了索引怎么建：ADDRESSBOOK_SET_SCOPE 上的联合索引前缀应该是 (ADDRESSBOOK_SET_ID, ADDRESSBOOK_SET_TYPE, USER_TYPE)，把范围收窄放在最前面。如果只建了 (USER_ID)，那么每次判定都要全表扫出所有单位的所有范围行，数据量一上来就是慢查询。
3.3 代理关系：双向字段、软取消和事项条件
代理设置是另一个把「状态」设计得很满的例子。AGENT 表里 AGENT_ID 是代理人、AGENT_TO_ID 是被代理人，两个方向都要能查，所以索引得建两条；AGENT_TYPE 区分 1 代理设置和 2 离职交接，两者共用一张表但业务含义完全不同；MATTER_TYPE 区分按处理人设置还是按发起人设置；START_DATE 和 END_DATE 划出代理窗口；CANCEL_DATE 加 CANCEL_FLAG 做软取消——不物理删除，因为代理期间产生的单据还要能追溯是谁代谁处理的。AGENT_DETAIL 用 APP 字段按应用维度拆分（一个代理可以只对某几个模块生效），AGENT_SCOPE 则存发起人范围，用 ENTITY_TYPE 加 ENTITY_ID 再走一次多态引用。
-- 某人当前生效的代理关系：时间窗口 + 未取消 + 排除离职交接 SELECT ID, AGENT_ID, AGENT_TO_ID, AGENT_TYPE, START_DATE, END_DATE FROM AGENT WHERE CANCEL_FLAG = 0 AND START_DATE <= :now AND (END_DATE IS NULL OR END_DATE >= :now) AND (AGENT_ID = :memberId OR AGENT_TO_ID = :memberId) -- 双向查询 ORDER BY START_DATE DESC;注意 END_DATE 的判空：很多实现把「长期有效」存成 NULL，也有存成 9999-12-31 的，两种写法在同一套系统里并存是常有的事，查询必须兼容。另外 AI_DEAL_CONDITION 表把「自动处理条件」做成了可配置：TEMPLATE_ID 定位流程模板，SENDER_ID 和 USER_ID 分别是发起人和处理人，DEAL_TYPE 枚举 0 回退、1 指定回退、2 撤销、3 终止、4 不同意、5 处理时长，SIGNLE_VIEW_PERIOD 存处理时长阈值。把操作类型和时长指标塞进同一张条件表，好处是一条规则能同时表达「谁在什么操作下、超过多久」就触发，坏处是 DEAL_TYPE = 5 时其他字段的语义就变了，读代码的人很容易误解。
4. 考勤模块的三层数据：流水、日统计、归档各管一段
4.1 排班链：TEAM 到 ARRANGE 到 CLASS 到 FIX_TIME
考勤的配置是一棵树，从根往下读：ATTENDANCE_TEAM 是考勤组，带 IS_NEW、START_DATE、END_DATE 三个字段做版本化——考勤规则按生效日期切换，历史统计必须按当时的规则算，所以旧版本不删，只把 IS_NEW 置 0。ATTENDANCE_ARRANGE 是排班（0 固定排班、1 周期排班）；ATTENDANCE_CLASS 是班次，CLASS_TYPE 表示一天 1 次、2 次还是 3 次，FLEX_TIME 是弹性时间，LATE_SERIOUS 是严重迟到阈值，ABSENT_WORK 是旷工判定，LEAVE_FIX_TIME 和 ATTEND_FIX_TIME 是允许晚走和晚到的宽限；再往下 ATTENDANCE_FIX_TIME 存每一段的具体时间点：WORK_TIME、END_TIME、EARLY_WORK_TIME（最早可签到）、LAST_END_TIME（最晚可签退），以及 ATTEND_REMIND 和 LEAVE_REMIND 两个提醒开关。ATTENDANCE_DAY 是这条链的落地：某天对应哪个排班、哪个班次、是不是工作日。
有一处细节值得停下来看：LATE_SERIOUS、ABSENT_WORK、FLEX_TIME 这些明明都是「分钟数」的字段，类型是 VARCHAR(50)。存成字符串之后，凡是涉及比较和排序的地方都得先转数字，跨库查询时还可能因为隐式转换把索引废掉。稳妥的做法是在应用层统一转换成分钟整数再比较，别指望数据库替你做。
4.2 ATTENDANCE_INFO 与 ATTENDANCE_HISTORY：结构与用途的差异
这两张表字段高度重合：OWNER_ID、DEPT_ID、SIGN_TIME、SIGN、LONGITUDE、LATITUDE、COUNTRY、PROVINCE、CITY、TOWN、STREET、NEAR_ADDRESS、ADDRESS_CODE、ADDRESS_TYPE、YEAR/MONTH/DAY、IMG_INFO、RECORD_INFO。差异才是信息所在。
| 差异点 | ATTENDANCE_INFO | ATTENDANCE_HISTORY |
|---|---|---|
| SIGN 长度 | VARCHAR(2000) | VARCHAR(500) |
| STATE | 有，3 上班迟到 / 4 下班早退 / 5 正常上班 / 6 正常下班 | 无 |
| MODIFY_NUM | 有，记录签到修改次数 | 无 |
| DEVICE_INFO / MAC_ADDRESS | 有，设备 ID 与 WIFI Mac | 无 |
| IS_WORK_DAY | 有 | 无 |
| 年月日冗余列 | 有 | 有 |
| 用途 | 活数据，可改可申诉，带防代打卡指纹 | 已归档，只读报表 |
SIGN 字段在两张表长度不一致，直接说明 INFO 表后期扩过列：原来只存地址或 IP，后来把定位描述一起拼进去，2000 才够。STATE 的枚举从 3 开始而不是从 0 或 1 开始，是另一个信号——1 和 2 曾经代表过别的含义，语义变更之后就地废弃，没人敢复用。这种「编号断档」在老系统里到处都是，看到枚举缺号，正确的反应是去代码里找历史映射，而不是自己补上 0 和 1。
至于为什么留两份结构相近的表：ATTENDANCE_INFO 是写入热点，每秒都在插，还要支持修改和申诉，索引要围绕 OWNER_ID 和 PUNCH_DATE 建；ATTENDANCE_HISTORY 是只读归档，数据量大但查询模式单一，可以按月分区、可以压缩、可以放冷存储。拆开之后，归档动作不会跟在线写入抢锁。IMG_INFO 和 RECORD_INFO 用 VARCHAR 存 JSON 而不是拆子表，理由也类似：图片和语音是补充证据，按图片维度反查的需求几乎没有，拆表只会增加一次 join。
4.3 ATTENDANCE_DAY_STATISTICS：把计算前移到写入时
这张表是典型的预聚合宽表：一人一天一行，AM_START_TIME、AM_END_TIME、PM_START_TIME、PM_END_TIME 四个时间点，加上四个对应的状态位，再加上 NORMAL_DAY（正常出勤天数）、AB_NORMAL_DAY（异常天数）、NONWORKDAYS_DAY（非工作日打卡天数）、LATE_NUM、LEAVE_EARLY_NUM、OUTSIDE_NUM、MISSINGCLOCK_COUNT、WORKING_MISSINGCLOCK、KNOCKOFF_MISSINGCLOCK、WORKING_MISSINGCLOCK、PUNCH_CLASS（应打卡次数 1 或 2）。一行的列数看着吓人，但它把「算」的成本从读时挪到了写时。
-- 月度报表：从日统计直接 SUM，不去碰流水表 SELECT MEMBER_ID, SUM(NORMAL_DAY) AS 正常出勤, SUM(AB_NORMAL_DAY) AS 异常天数, SUM(LATE_NUM) AS 迟到次数, SUM(LEAVE_EARLY_NUM) AS 早退次数, SUM(OUTSIDE_NUM) AS 外勤次数, SUM(MISSINGCLOCK_COUNT) AS 缺卡总数 FROM ATTENDANCE_DAY_STATISTICS WHERE ACCOUNT_ID = :accountId AND PUNCH_DATE >= :monthStart AND PUNCH_DATE < :nextMonthStart GROUP BY MEMBER_ID;这条 SQL 之所以能跑得快，全靠 PUNCH_DATE 上的索引和「一人一天一行」的粒度。如果换成从 ATTENDANCE_INFO 现场算，就要按人按天分组、判断工作日、比对排班时间、判定迟到早退，一次月度查询可能扫几十万行流水。预聚合的代价是：补卡、申诉、规则变更之后必须重算那一天的统计行，重算漏了就会出现「流水改了但报表没变」的数据不一致。PUNCH_CLASS 字段就是重算时的依据之一——它告诉你这一天应该打卡几次，缺卡数才能算对。
4.4 地理与附件：为什么经纬度不按规范存
按数据库设计规范，经纬度应该用 DECIMAL，比如 DECIMAL(10,6)；这套字典里 LONGITUDE 和 LATITUDE 都是 VARCHAR(50)。原因不难推：签到定位的数据来自第三方地图接口，接口返回的就是字符串，直接落库最省事，也不用处理空串、空格、负号、精度不一致这些情况。代价在处理侧——要算「是否在围栏内」，就得先 CAST 成 DECIMAL 或者交给应用层算，而 CAST 一旦碰上空串就是报错而不是 NULL。所以正确做法是：入库前统一格式化成固定小数位字符串，查询时用正则先过滤再转换，绝不能假设这一列一定是合法数字。ATTENDANCE_SETTING 里的 LONGITUDE、LATITUDE、ATTEND_REMIND、AVAILABLE 是围栏配置，RELATIVE_ID 用来存第三方系统导入的围栏 ID，这条设计说明围栏数据可能来自外部，进一步解释了为什么地理字段全程按字符串处理。
5. 排查与避坑：读这份数据字典时最容易翻车的五个地方
5.1 扩展字段只看到一个人，或者干脆是空
现象：明明在表单上选了三个审批人，查 EXT_ATTR_41 只看到第一个人的 ID，后面的人不见了。原因：41 到 50 段位定的是 VARCHAR(50)，一个 BIGINT 主键转成字符串大概 10 到 20 位，三个人拼起来必然超长，写入时被数据库截断或者被应用层截断。解决：先按主键查是否只有一个 ID，确认是截断；然后判断这个业务到底需要单选还是多选，多选就必须另建关联表或者把这段改成 VARCHAR(1024)，不能靠扩长度硬撑。排查脚本就一句：SELECT LENGTH(EXT_ATTR_41), EXT_ATTR_41 FROM ADDRESSBOOK WHERE LENGTH(EXT_ATTR_41) > 20;。
5.2 通讯录里某人看不到，但设置明明是「全部可见」
现象：用户反馈通讯录搜不到某个同事，管理员进设置页看查看范围是全单位。原因：ADDRESSBOOK_SET_SCOPE 里 ADDRESSBOOK_SET_TYPE 有 1、2、3 三种含义，分别对应查看范围、关键信息、导出与打印。查询可见性时漏了这个条件，就会把「导出权限」的明细误当成可见范围，或者反过来，把本该可见的实体过滤掉。解决：所有涉及这张表的查询都必须显式带上ADDRESSBOOK_SET_TYPE = 1，并且用 ADDRESSBOOK_SET_ID 关联到本单位（ACCOUNT_ID）的设置，别用全局设置去覆盖单位设置。
5.3 签到距离算出来是负数，报表里出现一堆异常
现象：围栏判断时抛出数字转换异常，或者距离算出来明显不对。原因：LONGITUDE、LATITUDE 是 VARCHAR，里面可能有空串、前后空格、超过合理范围的脏值，甚至有人在多地点打卡时把两个坐标拼在一列里。直接 CAST 就会报错或者得到错值。解决：转换前先用正则白名单过滤（^-?\d{1,3}(\.\d+)?$），过滤后再判范围（经度 -180 到 180，纬度 -90 到 90），不合法的一律当未定位处理，而不是当 0 处理——当 0 会让所有异常点落在赤道附近，报表看着像有人在南美打卡。
5.4 报表人数比通讯录少，或者翻倍
现象：人员总数统计出来跟通讯录对不上。原因：状态位没过滤干净。这套字典里的状态至少有四种形态——BBS 系列表里的 STATE 是 0 正常 1 删除；AGENT 里的 CANCEL_FLAG 是 0 未取消 1 已取消；ATTENDANCE_TEAM 的 IS_NEW 是 0 不是最新 1 是最新；ATTENDANCE_NO_REMIND_MEMBER 的 STATE 是 0 正常 1 废弃。这些字段名不一样、取值含义也不统一，任一漏掉都会串数据。解决：给每张表建一份「必带条件」清单，写查询前先对照；更彻底的做法是在数据访问层把这几类表包一层视图，把状态条件固化进去。
5.5 跨单位查询串数据，或者同一个 ID 出现两条记录
现象：多单位部署下，A 单位的报表里出现了 B 单位的人。原因：人员 ID 在不同单位下可能重复，所有业务表都冗余了 ACCOUNT_ID 或 ORG_ACCOUNT_ID 做隔离键，但查询时忘了带。ATTENDANCE_HISTORY、ATTENDANCE_DAY_STATISTICS、BBS_ARTICLE、AI_ORG_CHANGE_RECORD 都带这个字段，它不是冗余而是必须的过滤条件。解决：联合索引一律以 ACCOUNT_ID 打头，比如 (ACCOUNT_ID, PUNCH_DATE, MEMBER_ID)，既能保证隔离，又能让范围查询走上索引；并且约定所有查询构造器默认注入当前单位。
6. 设计取舍：宽表、冗余统计和无外键，值不值
6.1 宽表的实际代价比想象的小，但不是没有边界
很多人看到 70 个 EXT_ATTR 第一反应是「这么设计不规范」。先算一笔账：VARCHAR 和 DATETIME 在 InnoDB 里是变长存储，NULL 值只占 NULL 位图里的一个 bit，数据区不分配；DECIMAL(19,4) 是定长 9 字节左右。70 个扩展位全空时，每行真正多出来的只有一个 NULL 位图加上变长列的偏移数组，几字节到几十字节量级。所以在「扩展字段大面积空置、少数人用满」的分布下，宽表的存储代价不算高，换来的是免 join、强类型、ORM 直接映射三件事。真正的边界在列数上限和 DDL 成本：列数逼近三位数之后，任何一次表结构变更都是高风险动作，所以扩展位只能一次预留够，这也是为什么它一上来就是 70 个而不是 10 个。
6.2 预聚合与无外键：两个方向的取舍
ATTENDANCE_DAY_STATISTICS 把迟到次数、缺卡数这类指标在写入时就固化，是拿「一致性维护成本」换「读性能」。这个交换在考勤场景里划算，因为读远多于写，而且写入路径是单点的签到服务，重算可以由同一个服务触发。但如果换到工单、合同这种数据随时被修改的场景，预聚合会变成负担，改一次数据要重算一串统计。无外键的取舍同理：OA 的组织架构调整频率高到无法承受外键约束，所以接受脏数据风险，转而用 AI_ORG_CHANGE_RECORD、AI_ORG_MEMBER_CHANGE 这类变更记录表加上定时巡检来做一致性兜底。这套设计能成立，前提是「组织调整是低频但影响面大的操作」，可以接受用批处理补偿，而不是要求数据库实时保证。
6.3 我自己的三条自检习惯
拿到一份新版数据字典，我一般先做三件事。第一，grep 所有状态类字段（STATE、FLAG、IS_NEW、CANCEL_FLAG），把取值含义列成表，因为这类字段的编号断档和老语义是数据错乱的源头。第二，grep 所有带 ACCOUNT_ID、ORG_ACCOUNT_ID 的表，确认隔离键没有遗漏，多单位部署下的串数据问题一旦上线很难回溯。第三，把 EXT_ATTR 的段位表抄一份放进项目文档，任何读写扩展字段的代码都必须引用这个唯一来源，禁止硬编码下标。这三件事花了不到一小时，但省下来的排查时间远不止于此。
有一次做考勤报表，我图省事直接从流水表现算月度迟到次数，结果对不上人力的口径——因为漏了「非工作日打卡不计迟到」这一条，而这条规则只体现在日统计表的 IS_WORK_DAY 判定里。从那以后我每次碰这类有预聚合表的模块，都强制先把「流水、日统计、归档」三层的字段差异拉出来对比一遍，再动查询。这份 V8.1 数据字典把通讯录、代理、自动处理、组织调整、考勤、讨论区的表结构和字段含义都摊开了，正好可以拿它做一次逐表梳理，把上面这些坑在自己系统里对照检查一遍。希望帮到你。
本文还有配套的精品资源，点击获取
