科杰企业级系统（模块拆库与数据分层建议）

1. 文档定位

本文档用于说明科杰企业级系统在技术实施中的拆库边界、数据分层策略、读写分离方向和审计/附件存储建议。

目标是：

• 一期不过度复杂；
• 二期可平滑扩展；
• 避免未来因主数据混乱而被迫重构。

2. 一期推荐策略

2.1 一期不建议物理拆成多个数据库

推荐：

• 一个主业务库
• 按模块逻辑分 schema/table group
• 代码层按域分包

原因：

• 一期对象关系强；
• 跨域事务较多；
• 团队协作成本更低；
• 运维复杂度可控。

2.2 一期先“逻辑拆域”，二期再考虑“物理拆库”

建议先按业务域清晰分层：

• auth
• crm
• design
• equipment
• ledger
• service
• compliance
• file
• analytics
• iot

3. 一期逻辑分域建议

3.1 组织权限域

表：

• company
• department
• user_account
• role
• user_role_rel
• permission_action
• role_permission_rel

特点：

• 访问频率高
• 数据量不大
• 需要稳定、强一致

3.2 标准设计资产域

表：

• product_model
• electrical_scheme
• drawing_asset
• drawing_version
• plc_program
• plc_program_version
• bom_template
• bom_item
• engineering_change

特点：

• 版本控制重
• 文件关联重
• 读多写少

3.3 设备主档域

表：

• equipment
• equipment_archive
• archive_document
• equipment_version_binding
• delivery_package

特点：

• 全系统中心域
• 与台账、售后、合规强关联

3.4 台账域

表：

• inspection_task
• inspection_daily
• inspection_daily_item
• inspection_monthly
• maintenance_record
• annual_self_check
• rectification_task

特点：

• 写入频繁
• 时间序列属性明显
• 需要补录和审计能力

3.5 售后域

表：

• service_work_order
• service_dispatch
• service_visit_record
• service_part_usage
• service_feedback

特点：

• 流程型数据
• 需要移动端高频写入

3.6 合规域

表：

• compliance_case
• inspection_status_log
• export_package

特点：

• 风险管理
• 对外导出
• 强审计

3.7 附件与审计域

表：

• attachment_file
• signature_record
• operation_log

特点：

• 横切全部业务
• 文件量增长快
• 日志量增长更快

3.8 分析域

表：

• analytics_snapshot
• 统计宽表（后续）

特点：

• 更适合异步生成
• 不建议影响主事务库查询性能

4. 二期物理拆库建议

当系统进入二期、三期后，可以按以下顺序考虑拆分：

4.1 最容易独立拆出的域

• file / export 域
• notification 域
• analytics 域
• iot 域

原因：

• 与主事务解耦程度高；
• 可异步化；
• 资源类型差异明显。

4.2 中期可拆出的域

• service 域
• ledger 域

原因：

• 体量会明显增长；
• 可通过设备ID和工单ID关联；
• 可逐步独立服务化。

4.3 最晚拆出的域

• equipment 域
• design 域
• auth 域

原因：

• 这几个域是全系统中枢；
• 一旦过早拆分，跨域复杂度会显著上升。

5. 读写分离建议

5.1 一期

• 不强制上读写分离
• 先保证主库稳定
• 对分析和看板类查询做缓存或快照

5.2 二期

若数据增长明显，可引入：

• 主从复制
• 读写分离
• 分析快照库

优先读库使用场景

• 经营分析看板
• 统计报表
• 历史日志查询
• 大批量档案浏览

必须主库写读一致场景

• 登录鉴权
• 台账提交后回查
• 合规状态判断
• 审批状态查看

6. 附件存储建议

6.1 不把大文件存数据库

所有文件只存：

• 文件元数据在 attachment_file
• 文件内容放对象存储

6.2 附件路径建议

按业务域与日期组织：

• /design/drawing/2026/03/...
• /equipment/archive/...
• /ledger/signature/...
• /service/report/...
• /export/package/...

6.3 大文件类型

重点包括：

• 图纸
• PLC程序包
• 交付资料包
• 检验报告扫描件
• 台账签字页
• 导出压缩包

7. 审计日志存储建议

7.1 一期

• operation_log 存主库
• 建索引：module_code、biz_type、biz_id、operator_id、operated_at

7.2 二期

当日志量明显增长后：

• 审计日志独立库或日志平台
• 冷热分层存储
• 保留主库最近时间窗口，历史转档

8. 数据快照建议

对于以下统计，不建议实时扫业务表：

• 风险设备总量
• 各类台账完成率
• 工单关闭率
• 国产替代率
• 设备状态分布

建议：

• 每日/每小时异步生成 analytics_snapshot
• 看板优先读快照表

9. 归档与历史数据策略

9.1 高频增长数据

• inspection_daily
• service_visit_record
• operation_log
• attachment_file

这些表后期要考虑：

• 按月份/年度分区
• 归档旧数据
• 分析与交易分离

9.2 长期保留数据

• equipment
• product_model
• electrical_scheme
• archive_document
• compliance_case

这些表应长期保留，不能轻易清理。

10. 索引建议

10.1 设备相关高频索引

• equipment_code
• registration_no
• model_id
• operation_status
• risk_level

10.2 台账相关高频索引

• equipment_id + task_type + plan_date
• equipment_id + check_date
• status + due_date

10.3 工单相关高频索引

• work_order_no
• equipment_id + status
• assignee_id + status

10.4 审计与附件相关索引

• biz_type + biz_id
• uploaded_at
• module_code + operated_at

11. 未来数据中台方向（后续）

如果后续系统继续扩大，可以逐步形成：

• 事务库层
• 文件与导出服务层
• IoT 时序数据层
• 分析仓库层
• 对外开放接口层

但这不建议在一期同步做重型建设。

12. 结论

科杰系统的一期，最合理的方式不是一开始拆成很多数据库，而是：

• 代码先分域
• 数据先逻辑分层
• 文件、导出、分析、IoT 提前预留边界
• 等业务量和团队能力成熟后，再逐步物理拆分

这样既能保证交付效率，也能保留后续升级空间。