审计日志数据模型需字段语义清晰、时间精度可控、查询路径明确；Navicat可辅助校验类型与约束，但建模前须确认数据库类型及版本，并严格设计字段、外键、索引与同步策略。
审计日志数据模型不是“画出来就行”，关键在于字段语义清晰、时间精度可控、查询路径明确。navicat 本身不校验业务逻辑，但能帮你把 created_at 设成 timestamp with time zone，也能让你一眼看出外键没建全——这比手写 ddl 少踩 70% 的坑。
选对数据库类型和版本再建模
审计日志对时区、序列、JSON 支持敏感，建模前必须确认目标库类型和版本：
- PostgreSQL 12+：优先用
jsonb存操作详情，pg_catalog.pg_timezone_names()可查时区支持 - MySQL 8.0+：
TIMESTAMP自动转本地时区，若需 UTC 应统一用DATETIME+ 应用层控制 - SQL Server 2016+：可用
SEQUENCE替代自增主键，避免高并发下日志 ID 冲突 - Oracle：注意
SYSTIMESTAMP和CURRENT_TIMESTAMP的行为差异，前者含时区，后者按会话时区
Navicat Data Modeler 在新建模型时要求选择「数据库供应商」和「版本号」，选错会导致后续生成的 DDL 缺失关键语法（比如漏掉 GENERATED ALWAYS AS ROW START 这类系统版本控制字段）。
核心表字段设计要匹配审计场景
常见错误是把 user_id 当成字符串存，结果关联用户表时类型不匹配；或把 action 设为 VARCHAR(10)，后期加个 “user_password_reset” 就爆字段。
-
audit_log表至少包含：id（主键）、event_time（带时区的时间戳）、user_id（与用户表主键类型严格一致）、operation（ENUM或VARCHAR(32)，预设值如 'INSERT'/'UPDATE'/'DELETE'/'LOGIN'）、target_table、target_id、before_data（JSON类型）、after_data（JSON类型）、ip_address（INET或VARCHAR(45)） - 外键约束必须显式设置：
user_id→users.id，否则 Navicat 同步到库时不会自动建 FK，日志就成孤岛数据 - 索引不是可选项：至少建复合索引
(event_time, operation, user_id)，Navicat 的「索引设计器」里要手动勾选「升序」并确认「非唯一」
逆向工程已有日志表时容易漏的关键点
很多团队已有现成日志表，想用 Navicat 做可视化梳理——但直接「逆向表到模型」常丢信息：
- 注释（COMMENT）不会自动导入到模型字段说明里，得双击字段 → 「备注」栏手工补全，否则导出文档时缺失上下文
- MySQL 的
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP在模型里只显示为DEFAULT CURRENT_TIMESTAMP，少了一半逻辑，需在「默认值」栏手动补全完整表达式 - PostgreSQL 的
GENERATED ALWAYS AS (now() AT TIME ZONE 'UTC')计算列，在逆向后变成普通TIMESTAMP，必须进字段属性 → 「表达式」页签重填 - 如果原表用了触发器自动填充审计字段，Navicat 模型里完全不可见，得靠 DBA 提供触发器 SQL 手动加到模型「函数/过程」对象里
同步模型到数据库前必做的三件事
点击「同步到数据库」按钮前，Navicat 会生成对比脚本，但默认忽略以下风险项：
- 检查「比对选项」里是否勾选了「比较列默认值」和「比较检查约束」，否则
CHECK (event_time <= now())这类约束会被跳过 - 确认目标库字符集：若模型用
utf8mb4而库是latin1，同步会失败且报错模糊（只提示「DDL error」，不指明字符集冲突） - 大表加字段慎用：Navicat 默认生成
ALTER TABLE ... ADD COLUMN，但 MySQL 5.7 对千万级audit_log表执行会锁表，得提前在「高级选项」里勾选「使用在线 DDL」（对应ALGORITHM=INPLACE）
审计日志表一旦上线，字段变更成本极高——不是改个模型就能同步的，每次同步都得人工核对生成的 SQL 是否含 LOCK=NONE 或 CONCURRENTLY 这类关键字。
