多租户模型设计前必须确认三件事：一是选择租户隔离方式（共享库+共享表/独立表/独立库）；二是确认数据库对动态schema、RLS等特性的支持；三是明确Navicat仅用于建模，租户上下文逻辑需人工实现。
多租户模型设计前必须确认的三件事
navicat本身不强制实现多租户，它只提供建模工具；真正决定租户隔离方式的是你选的数据库引擎和业务逻辑。别一上来就拖表——先想清楚：用共享数据库+共享表（靠tenant_id字段隔离），还是共享数据库+独立表（按租户前缀命名），或是完全独立数据库？这三种方案在navicat里都能画出来，但后续sql生成、权限配置、备份策略全都不一样。
常见错误是把所有租户数据塞进一张user表，然后靠应用层过滤WHERE tenant_id = ?，结果忘了加索引，或漏写条件导致数据越界。Navicat的ER图不会帮你检查这个。
- 确认数据库是否支持动态schema切换（如PostgreSQL的
SET search_path，MySQL不原生支持） - 检查目标数据库版本对
DEFINER、行级安全策略（RLS）的支持情况（PostgreSQL 14+、Oracle 12c+才有成熟RLS） - 明确Navicat是否用于生产环境管理——若只是建模用，导出DDL后仍需人工调整租户上下文相关逻辑
在Navicat模型设计器中正确添加租户字段
不是所有字段都适合叫tenant_id。Navicat建模时，字段名本身不带语义，但会影响后续代码生成和团队理解。建议统一使用tenant_id（整型/UUID），避免用org_id、company_code等模糊名称。
关键操作不是“加字段”，而是“设约束”：
- 给每个业务表（如
order、product）添加tenant_id字段，并设为NOT NULL - 在Navicat模型中右键该字段 → “设置为主键的一部分”或“添加复合索引”，确保
(tenant_id, id)或(tenant_id, created_at)被显式定义 - 不要依赖Navicat自动生成的外键——
tenant_id通常不指向其他表，它是逻辑隔离标识，不是引用完整性约束
示例：建tenant_config表时，tenant_id是主键；建tenant_user表时，(tenant_id, user_id)组成联合主键——Navicat能可视化这些关系，但不会自动阻止你在INSERT时漏传tenant_id。
逆向工程已有租户库时容易忽略的细节
用Navicat的“逆向工程”从现有数据库生成模型，常因权限或结构问题漏掉租户关键信息：
- 如果数据库用户只有
SELECT权限，Navicat无法读取COMMENT字段说明，租户字段的业务含义会丢失 - MySQL 8.0+下，若租户表用了
JSON字段存储动态配置，Navicat模型会显示为JSON类型，但不会展开内部schema——这意味着你无法在模型里看到tenant_config.data → $.region这种路径约束 - PostgreSQL的
partitioned table按tenant_id分区时，Navicat逆向后只显示主表，不自动还原分区子表结构，需手动补全
验证方法：生成模型后，右键任意表 → “查看DDL”，检查CREATE TABLE语句里是否有tenant_id字段、是否加了INDEX、是否设置了DEFAULT值（比如tenant_id INT DEFAULT current_setting('app.tenant_id')::int这种PG特有写法）。
导出模型到不同数据库时的兼容性陷阱
Navicat模型导出为SQL脚本时，tenant_id字段的类型选择直接影响跨库迁移：
- MySQL用
BIGINT UNSIGNED存租户ID，PostgreSQL对应BIGSERIAL，但Oracle需要改用NUMBER(19)——Navicat不会自动转换，导出前必须手动编辑字段类型 - 若模型里定义了
tenant_id为VARCHAR(32)（适配UUID），导出到MySQL时可能生成VARCHAR(32) COLLATE utf8mb4_bin，而SQL Server默认排序规则不兼容，插入时会报Cannot resolve collation conflict - Navicat的“结构同步”功能对比两个库时，会把
tenant_id字段的DEFAULT表达式当作差异项——哪怕逻辑一致（如MySQL的CURRENT_USER()和PG的current_user），也会提示“需更新”，得手动跳过
最稳妥的做法：模型只定义字段名、是否为空、索引；类型、默认值、注释等数据库特有属性，留到导出后人工校验并修补。别指望Navicat一步到位。
