使用 UUID 作为跨数据库通用主键的 DAO 设计实践-Golang-PHP中文网

使用 UUID 作为跨数据库通用主键的 DAO 设计实践

本文介绍如何在基于 dao 模式的多数据库（如 mysql、postgresql 与 mongodb）应用中，统一 id 字段设计，推荐采用 uuid v4 作为全局唯一标识符，避免 bson objectid 与整型主键之间的类型冲突，实现数据层解耦与业务逻辑一致性。

本文介绍如何在基于 dao 模式的多数据库（如 mysql、postgresql 与 mongodb）应用中，统一 id 字段设计，推荐采用 uuid v4 作为全局唯一标识符，避免 bson objectid 与整型主键之间的类型冲突，实现数据层解耦与业务逻辑一致性。

在构建支持多种持久化后端（如关系型数据库与 MongoDB）的系统时，DAO 层需屏蔽底层存储差异。一个核心挑战是 ID 字段的类型不一致：SQL 数据库通常使用 uint64 或自增整数作为主键，而 MongoDB 原生使用 ObjectID（12 字节 BSON 类型），二者语义、长度、生成方式及序列化行为均不同。若强行在结构体中定义多态 ID 字段（如嵌套 BSONID uint 和 SQLID uint64），不仅增加维护成本，更易引发运行时类型转换错误或 API 序列化歧义。

推荐方案：统一采用 UUID v4 作为逻辑主键（UID）

UUID v4 是完全随机生成的 128 位标识符（格式如 f47ac10b-58cc-4372-a567-0e02b2c3d479），具备全局唯一性、无序性、无需中心协调器等优势，天然适合作为跨数据库的通用主键。它既可安全存入 SQL 的 CHAR(36) 或 UUID 类型字段（PostgreSQL 原生支持），也可作为 MongoDB 文档中的字符串字段（uid: "..."），同时兼容 JSON REST API 传输与 Go 结构体字段（string 类型）。

✅ 实施要点：

DrugBank 数据库

访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-

下载

结构体定义：所有领域实体统一使用 UID string 字段，而非 ID uint64 或 ID primitive.ObjectID。

DAO 接口抽象：DAO 方法签名统一以 UID 为参数/返回值，例如：

type UserDAO interface {
    Create(ctx context.Context, user *User) error
    GetByUID(ctx context.Context, uid string) (*User, error)
    DeleteByUID(ctx context.Context, uid string) error
}

数据库映射：
- SQL：users 表添加 uid CHAR(36) UNIQUE NOT NULL，主键仍可保留自增 id BIGINT PRIMARY KEY 仅作内部索引，业务逻辑全程使用 uid 查询；
- MongoDB：文档中显式存储 "uid": "..." 字段，并创建 { uid: 1 } 索引，查询时使用 bson.M{"uid": uid}；

生成与校验：使用标准库（如 Go 的 github.com/google/uuid）生成 v4 UUID，并在创建实体时自动赋值：

func NewUser(name string) *User {
    return &User{
        UID:  uuid.NewString(), // 自动生成标准 UUID v4 字符串
        Name: name,
    }
}

⚠️ 注意事项：

避免将 UUID 用作 SQL 主键（尤其在高并发插入场景），因其随机性可能导致 B+ 树页分裂；建议保留自增 ID 为主键，uid 作为业务主键 + 唯一约束；
MongoDB 中勿覆盖 _id 字段为 UUID（虽技术可行），因 _id 索引性能最优且驱动深度集成；应额外存储 uid 并确保其唯一性；
REST API 响应中直接暴露 uid 字段（如 {"uid": "xxx", "name": "Alice"}），无需额外编码（如 MD5），既保持语义清晰，又避免哈希碰撞风险；
若需兼容遗留系统或审计需求，可在 DAO 实现中桥接 uid ↔ SQL id 或 uid ↔ ObjectID，但上层业务代码完全无感知。