#PostgreSQL #数据库设计 #EF Core #工程实践

PostgreSQL 表名与字段命名规范：为什么 snake_case 是唯一正确选择

在 PostgreSQL 项目中，表名和字段名的命名方式，从来不是个人偏好问题。

如果你在项目早期没有统一规范，后期一定会遇到这些情况：

  • 表名大小写混乱
  • SQL 查询必须加双引号
  • EF Core 映射异常
  • 数据库和代码之间长期不一致
  • 新人一写 SQL 就出错

我们在多个 PostgreSQL + EF Core 项目中踩过这些坑，最终只留下了一条结论：

PostgreSQL 中，snake_case 是唯一值得长期使用的命名方式。

PostgreSQL 的一个“隐藏规则”

先说一个很多人第一次用 PostgreSQL 都会踩的坑。

CREATE TABLE SupportTicket (...);

你以为创建的是 SupportTicket， 实际上 PostgreSQL 会把它变成：

supportticket

如果你坚持要保留大小写，只能写成：

CREATE TABLE "SupportTicket" (...);

但代价是：

SELECT * FROM "SupportTicket"; -- 每一次都必须加引号

一旦开始使用双引号，你的数据库就进入了“引号地狱”。

最终结论（可以直接记住）

PostgreSQL 中：

  • 表名、字段名统一使用 snake_case
  • 全部小写
  • 永远不要依赖双引号
  • 不要使用驼峰命名

这不是偏好，而是 PostgreSQL 的设计现实。

表名命名规范（Table）

✅ 推荐规则

  • snake_case
  • 单数
  • 语义明确
  • 不加前缀
❌ 不推荐✅ 推荐
SupportTicketssupport_ticket
UserProfilesuser_profile
tbl_useruser

为什么用单数？

  • 表在语义上更接近 实体 / 聚合根
  • 与 DDD 的模型一致
  • SQL 语句更自然

字段命名规范（Column）

✅ 基本规则

  • snake_case
  • 不加表名前缀
  • 语义清晰
❌ 不推荐✅ 推荐
UserIduser_id
CreatedAtcreated_at
IsDeletedis_deleted

主键与外键命名

主键（Primary Key）

id
id uuid primary key
-- 或
id bigint generated always as identity

主键不需要语义，它只是“身份”。

外键（Foreign Key）

{referenced_table}_id
user_id
order_id
support_ticket_id

布尔字段（Boolean）

is_xxx
has_xxx
is_active
is_deleted
has_attachment

时间字段（Timestamp）

*_at
created_at
updated_at
deleted_at

强烈建议统一使用 UTC 时间。

索引与约束命名规范（强烈推荐）

虽然 PostgreSQL 不强制，但团队必须统一。

pk_{table}              -- 主键
fk_{table}_{column}     -- 外键
ix_{table}_{column}     -- 普通索引
ux_{table}_{column}     -- 唯一索引

示例：

pk_support_ticket
fk_support_ticket_user_id
ix_support_ticket_created_at
ux_user_email

EF Core + PostgreSQL 的最佳实践

C# 实体（领域模型）

public class SupportTicket
{
    public Guid Id { get; private set; }
    public string Title { get; private set; }
    public bool IsDeleted { get; private set; }
    public DateTime CreatedAt { get; private set; }
}

数据库结构

support_ticket
id
title
is_deleted
created_at

启用自动 snake_case 映射（强烈推荐）

options.UseSnakeCaseNamingConvention();

这样你可以做到：

  • 领域模型：PascalCase
  • 数据库：snake_case
  • 不写一行多余映射代码

这不是“风格问题”，而是成本问题

数据库命名一旦上线，修改成本极高：

  • SQL
  • 迁移
  • 报表
  • 运维脚本
  • 第三方系统对接

命名规范选错一次，成本会伴随整个系统生命周期。

总结

如果你的项目满足以下任意一条：

  • PostgreSQL
  • 多人协作
  • EF Core / ORM
  • 长期维护

那么请直接采用这套规则：

snake_case + 小写 + 单数表名 + 禁止双引号

这是我们在多个实际项目中， 用时间和踩坑换来的结论。

如果你正在构建基于 PostgreSQL 的企业级系统， 越早统一命名规范，后期越省心。

微信订阅号二维码