数据库教程FGMT47‑PostgreSQL数据类型与数据库设计规范

### 前言
风哥教程本文面向数据库DBA、运维工程师、数据库架构师、后端开发人员，完整讲解数据库对象设计、字符集与本地化、各类数据类型选型、生产环境表结构设计规范。数据库设计是业务系统根基，不合理的字段类型、错误的字符集排序规则、混乱的schema划分，会带来索引失效、排序异常、存储膨胀、查询性能低下、业务数据错乱等一系列难以修复的问题；很多故障在上线之后无法直接修改，只能重建数据库迁移数据，维护成本极高。

本套风哥教程使用两台标准化主机`fgedu‑net‑cn1`、`fgedu‑net‑cn2`，硬件规格统一**64G内存、8CPU**；数据根目录统一使用`/fgedudb`；实例名、业务数据库名、业务用户名固定为`fgedudb`、`fgedudb`、`fgedu`。风哥教程本文包含底层设计理论、完整可复现实战SQL命令、案例数据库初始化、常见陷阱规避、生产设计规范，帮助从业者建立标准化PostgreSQL数据库对象设计思维。

>
> 风哥 itpux‑com

### 风哥教程本文内容大纲

1. SQL语言基础与案例环境初始化：psql登录连接操作；案例演示库部署；数据库对象层级关系理论。
2. 字符集与本地化理论：编码、LC_COLLATE、LC_CTYPE底层原理；数据库与集群locale的约束，生产选型原则。
3. 数据库对象管理实战：数据库创建、修改、删除；schema模式创建、授权、搜索路径配置；schema在微服务、多租户场景落地实操。
4. 数据表管理实战：建表语法，各类约束（主键、非空、唯一、check、外键）；表修改、重命名、删除；TOAST存储机制。>
> 风哥教程 113257174
5. PostgreSQL全量数据类型详解理论：数值类型、字符类型、时间类型、JSON/JSONB、布尔、网络地址类型；每种类型存储原理、适用场景、常见踩坑点。
6. 数据类型实战演练：各类类型建表示例，增删改查操作，类型之间转换实操，JSONB索引实战。
7. 生产数据库设计规范：命名规范、字段选型规范、约束使用原则、索引设计、schema划分、字符集落地规范、反模式与避坑清单。
8. 案例库综合演练：基于业务场景完整建库、schema、表、权限全套DDL脚本；巡检脚本输出表结构风险点。
9. 风哥针对本文总结：设计关键点复盘，上线前检查清单。

本套风哥教程篇幅分配：前言大纲占全文5%；底层理论原理占全文30%；实战SQL、命令操作演练占全文60%；结尾总结占全文5%。

## 一、SQL语言基础与案例环境初始化理论

### 1.1 对象层级结构理论

PostgreSQL对象层级自上而下：数据库集群（实例cluster）→Database数据库→Schema模式→表、视图、索引、函数、序列。

– 一套实例可以创建多个Database；**psql客户端一次连接只能访问一个Database，跨Database不能直接访问普通表对象，需要fdw/dblink扩展**。
– 每个Database内部可以划分若干schema；schema相当于命名空间，用来隔离业务模块，同一个库内可以跨schema直接访问表，不需要扩展组件。
– 默认新建数据库自带`public` schema，如果建表不指定schema，对象默认创建到public下面。生产业务不建议全部对象堆积在public。

>
> 风哥数据库教程 itpux‑com

### 1.2 psql客户端连接原理

psql是官方自带交互式客户端，支持unix‑socket本地连接与TCP网络连接。unix‑socket不走TCP协议，性能更高，仅本机可用；TCP连接支持跨主机访问，受pg_hba.conf访问控制文件管控。连接时需要指定实例地址、端口、数据库名、数据库用户名。

### 1.3 环境初始化实战操作

实操主机`fgedu‑net‑cn1`，已经部署好数据库实例，数据目录`/fgedudb/fgedudb_data`。

#### 1.3.1 psql多种登录方式

“`
# unix socket本地登录，操作系统postgres用户
su – postgres
psql -d postgres

# TCP网络登录，指定IP端口数据库用户名
psql -h 127.0.0.1 -p 5432 -U fgedu -d fgedudb

# 指定socket文件路径登录
psql -h /fgedudb/fgedudb_data -d fgedudb
“`

psql元命令，不需要分号，反斜杠开头，常用：

“`
\l #查看全部数据库列表
\dn #查看当前库所有schema
\dt #查看当前schema下面所有表
\d 表名 #查看表结构详情
\du #查看角色用户
\q #退出psql终端
“`

#### 1.3.2 部署风哥教程案例业务数据库

业务案例库数据库名`fgedudb`，业务账号`fgedu`，用于后续全部演示。

“`
–创建业务数据库，模板选择template0，避免继承模板库的污染对象
CREATE DATABASE fgedudb
ENCODING ‘UTF8′
LC_COLLATE=’C’
LC_CTYPE=’C’
TEMPLATE template0;

–创建业务登录角色
CREATE ROLE fgedu LOGIN PASSWORD ‘FgEdU@2026’;
GRANT CONNECT ON DATABASE fgedudb TO fgedu;

–切换进入业务数据库
\c fgedudb
“`

>
> 网上搜索风哥教程可以学习全套数据库教程

## 二、字符集与本地化理论与实战

### 2.1 字符集与Locale核心理论

两个概念需要严格区分：**字符集ENCODING**，存储文本的字节编码，业务几乎全部选择UTF‑8；**Locale本地化参数，LC_COLLATE字符串排序规则、LC_CTYPE字符分类规则**。

重点不可逆约束：**数据库创建完成之后，LC_COLLATE、LC_CTYPE不能ALTER DATABASE直接修改**，这两个参数决定B‑Tree索引排序行为、order by字符串排序结果；一旦业务上线发现locale错误，只能新建数据库，dump数据重新导入，无法原地修改修复。

三层生效范围：

1. 集群层（initdb初始化实例时）：所有新建数据库默认继承集群locale；
2. 数据库层（CREATE DATABASE指定）：每个数据库独立一套collate与ctype；
3. 列/索引层：可以单独定义collation，对指定字段使用特殊排序规则。

`C` locale按字节进行字符串比较，索引性能高，不受操作系统本地语言包影响，备份迁移兼容性强，互联网业务绝大多数场景优先选用`C`；如果业务必须中文拼音排序，则操作系统需要安装`zh_CN.UTF‑8` locale，建库指定对应参数。

客户端编码与服务端编码可以不一致，数据库会自动做转码转换；查看数据库字符集信息，查询系统视图`pg_database`。

>
> 上51CTO搜索风哥可以学习全套数据库教程

### 2.2 字符集与Locale实战操作

#### 2.2.1 查看实例数据库字符集信息

登录psql执行：

“`
SELECT datname,encoding,datcollate,datctype FROM pg_database;
“`

字段说明：

– datname：数据库名称；
– encoding：编码编号；
– datcollate：LC_COLLATE；
– datctype：LC_CTYPE。

#### 2.2.2 查看操作系统支持哪些locale

操作系统shell执行（root或者postgres）

“`
locale -a
“`

#### 2.2.3 创建数据库两种模板示例

场景1：互联网业务，性能优先，C locale（推荐）

“`
CREATE DATABASE fgedudb
ENCODING ‘UTF8′
LC_COLLATE=’C’
LC_CTYPE=’C’
TEMPLATE template0;
“`

场景2：业务需要中文拼音排序，操作系统已经安装zh_CN.UTF‑8

“`
CREATE DATABASE fgedudb_cn
ENCODING ‘UTF8′
LC_COLLATE=’zh_CN.UTF‑8′
LC_CTYPE=’zh_CN.UTF‑8’
TEMPLATE template0;
“`

>
> 注意：TEMPLATE必须写template0；template1会复制已有数据库设置，会带来字符集冲突隐患。

#### 2.2.4 客户端编码设置

psql会话级别设置客户端编码：

“`
SET client_encoding = ‘UTF8’;
SHOW client_encoding;
“`

## 三、数据库与Schema模式管理理论与实战

### 3.1 Database数据库管理理论

Database是一套独立的数据库集合，拥有自己的字符集、locale参数；不同database之间隔离，不能直接跨库查询普通表。数据库对象包含schema、表、角色权限、表空间映射。
生产环境实践：**不要一个实例创建大量小Database；微服务业务优先单Database，不同业务模块使用schema做隔离，减少多库运维负担**。

### 3.2 Schema模式核心理论

schema是Database内部命名空间，用来做业务模块隔离。同一database内部，可以跨schema访问对象，语法为`schema_name.table_name`。
典型落地场景：

1. 微服务拆分：每个微服务分配独立schema；
2. 多租户模式：每个租户独立schema；
3. 区分业务表、归档表、中间计算表；
4. 权限隔离：业务账号只授予对应schema权限，不访问其他模块。

search_path搜索路径：当SQL不写schema前缀时，数据库按照search_path顺序依次查找对象；修改search_path可以简化SQL，不需要每次写schema前缀。
默认每个database自带`public` schema；多人共用库时建议限制public的create权限，避免开发人员随意建表到public。

>
> 风哥 itpux‑com

### 3.3 Database数据库实战操作

登录postgres库执行：

“`
–创建数据库
CREATE DATABASE fgedudb TEMPLATE template0 ENCODING ‘UTF8′ LC_COLLATE=’C’ LC_CTYPE=’C’;

–修改数据库所有者
ALTER DATABASE fgedudb OWNER TO fgedu;

–修改数据库连接限制，0表示无限制
ALTER DATABASE fgedudb CONNECTION LIMIT 100;

–删除数据库，数据库不能存在活跃会话连接
DROP DATABASE IF EXISTS fgedudb;
“`

### 3.4 Schema模式完整实战

切换进入业务库`\c fgedudb`。

#### 3.4.1 schema创建、授权、搜索路径设置

“`
–创建业务模块schema
CREATE SCHEMA IF NOT EXISTS fg_user;
CREATE SCHEMA IF NOT EXISTS fg_order;
CREATE SCHEMA IF NOT EXISTS fg_archive;

–schema指定所有者
CREATE SCHEMA IF NOT EXISTS fg_report AUTHORIZATION fgedu;

–查看当前库全部schema
\dn

–授予业务账号fg_user schema的使用、创建权限
GRANT USAGE,CREATE ON SCHEMA fg_user TO fgedu;
GRANT USAGE,CREATE ON SCHEMA fg_order TO fgedu;

–设置会话search_path，优先fg_user，其次public
SET search_path TO fg_user,public;
SHOW search_path;

–全局修改角色默认search_path，该账号登录自动生效
ALTER ROLE fgedu SET search_path TO fg_user,fg_order,public;
“`

>
> 风哥教程 113257174

#### 3.4.2 schema删除操作

“`
–仅schema为空时可以删除
DROP SCHEMA IF EXISTS fg_archive;

–级联删除schema连同下面全部表、视图等对象，生产谨慎使用
DROP SCHEMA IF EXISTS fg_archive CASCADE;
“`

#### 3.4.3 在指定schema创建表

“`
CREATE TABLE fg_user.t_user(
id bigint primary key,
username text not null
);
–访问指定schema表
SELECT * FROM fg_user.t_user;
“`

## 四、数据表管理理论与实战

### 4.1 表基础理论

PostgreSQL表是堆表（Heap Table），数据存储在数据页；大字段超过阈值会交给TOAST机制压缩存储到独立TOAST表，避免主数据页膨胀。
表约束类型：

1. PRIMARY KEY主键：唯一+非空，自动创建B‑Tree索引，一张表只能一个主键；
2. NOT NULL非空约束：字段禁止存储NULL；
3. UNIQUE唯一约束：字段不能重复，可以允许多个NULL；
4. CHECK检查约束，自定义表达式校验写入数据；
5. FOREIGN KEY外键约束，维护两张表参照完整性。

### 4.2 创建表实战完整案例

连接`fgedudb`，search_path已经设置到fg_user。

“`
CREATE TABLE fg_user.t_user(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
username TEXT NOT NULL,
phone TEXT,
email TEXT,
age INTEGER CHECK(age >= 0 AND age <=120),
register_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
is_enable BOOLEAN DEFAULT true
);

CREATE TABLE fg_order.t_order(
order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
user_id BIGINT NOT NULL,
order_no TEXT NOT NULL UNIQUE,
amount NUMERIC(12,2) NOT NULL CHECK(amount >= 0),
create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
–外键关联用户表主键
FOREIGN KEY(user_id) REFERENCES fg_user.t_user(id)
);
“`

查看完整表结构：

“`
\d fg_user.t_user
\d fg_order.t_order
“`

>
> 网上搜索风哥教程可以学习全套数据库教程

### 4.3 表修改ALTER TABLE实战

“`
–新增字段
ALTER TABLE fg_user.t_user ADD COLUMN nick_name TEXT;

–修改字段类型
ALTER TABLE fg_user.t_user ALTER COLUMN nick_name TYPE VARCHAR(100);

–增加非空约束
ALTER TABLE fg_user.t_user ALTER COLUMN nick_name SET NOT NULL;

–删除字段，生产谨慎
ALTER TABLE fg_user.t_user DROP COLUMN IF EXISTS nick_name;

–增加检查约束
ALTER TABLE fg_user.t_user ADD CONSTRAINT ck_age CHECK(age>=0);

–重命名表
ALTER TABLE fg_user.t_user RENAME TO t_user_info;

–修改表所属schema
ALTER TABLE fg_user.t_user_info SET SCHEMA fg_archive;
“`

### 4.4 删除表操作

“`
DROP TABLE IF EXISTS fg_user.t_user_info;
–级联删除，同时删除外键依赖对象
DROP TABLE IF EXISTS fg_order.t_order CASCADE;
“`

### 4.5 TOAST存储查看实操

TOAST用来存储大文本、大二进制，字段存储策略PLAIN / EXTENDED / MAIN / EXTERNAL。

“`
–查看表TOAST信息
SELECT relname,reltoastrelid FROM pg_class WHERE relname=’t_user’;
–修改字段存储策略
ALTER TABLE fg_user.t_user ALTER COLUMN username SET STORAGE EXTENDED;
“`

>
> 上51CTO搜索风哥可以学习全套数据库教程

## 五、PostgreSQL数据类型理论详解

### 5.1 数值类型理论

#### 整数类型

| 类型 | 字节 | 取值范围 | 使用建议 |
| — | — | — | — |
| SMALLINT | 2字节 | -32768 ~ 32767 | 极少使用，存储空间有限 |
| INTEGER(int) | 4字节 | -2147483648 ~ 2147483647 | 普通ID、数量 |
| BIGINT | 8字节 | -9223372036854775808 ~ 9223372036854775807 | **主键ID优先选bigint** |

>
> 主键ID，业务尽量选用BIGINT，避免int溢出风险；GENERATED ALWAYS AS IDENTITY是推荐自增方案，不建议使用旧serial。

#### 精确小数NUMERIC/DECIMAL

`NUMERIC(p,s)`，p总有效位数，s小数位数；**金额财务业务必须用numeric，禁止float/double，避免浮点精度丢失**。

#### 浮点类型

REAL(4字节)，DOUBLE PRECISION(8字节)；科学计算、不需要严格精度场景使用；财务业务禁止使用浮点类型存储金额。

### 5.2 字符类型理论

1. `char(n)`固定长度，不足自动填充空格，查询会带来隐形问题，尽量少用，仅身份证等严格固定长度场景使用；
2. `varchar(n)`可变长度，限制最大字符数量；
3. `text`无长度上限，生产优先推荐text；需要限制业务长度，使用CHECK约束`CHECK(LENGTH(col)<=200)`，比varchar(n)更灵活。

### 5.3 时间日期类型

1. `DATE`：仅日期（年月日）；
2. `TIME`：仅时间；
3. `TIMESTAMP`不带时区时间；
4. `TIMESTAMPTZ`带时区时间戳，**生产业务强烈优先选择timestamptz**，自动处理时区转换，跨时区业务不会出现时间偏移错误；
5. `INTERVAL`时间间隔，存储时间段。

### 5.4 JSON与JSONB类型理论

– `json`：存储原始文本，每次读取重新解析；不支持GIN索引；适合日志原始报文只存储极少查询场景。
– `jsonb`：二进制解析存储，去除多余空格，键顺序不保留；支持GIN索引；业务JSON查询场景**优先jsonb**，可以做包含、键值查询索引加速。

### 5.5布尔、网络地址类型

boolean取值 true/false/null；cidr/inet存储IP网段与IP地址，比text更适合IP存储，自带IP相关函数。

>
> 风哥 itpux‑com

## 六、数据类型实战演练

全部在`fgedudb`数据库fg_user schema执行。

### 6.1 数值类型实操建表与DML

“`
CREATE TABLE fg_user.t_datatype_num(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
int_col INTEGER,
bigint_col BIGINT,
amount NUMERIC(14,2),
double_col DOUBLE PRECISION
);

INSERT INTO fg_user.t_datatype_num(int_col,bigint_col,amount,double_col)
VALUES(100,100000000,12345.67,3.1415926);

SELECT * FROM fg_user.t_datatype_num;
“`

### 6.2 字符类型实操

“`
CREATE TABLE fg_user.t_datatype_char(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
id_card CHAR(18),
username VARCHAR(64),
remark TEXT CHECK(LENGTH(remark)<=1000)
);

INSERT INTO fg_user.t_datatype_char(id_card,username,remark)
VALUES(‘510101199001011234′,’zhangsan’,’这是用户备注信息’);

SELECT id_card,char_length(id_card),username FROM fg_user.t_datatype_char;
“`

>
> 风哥教程 113257174

### 6.3 时间类型实操，timestamptz时区演示

“`
CREATE TABLE fg_user.t_datatype_time(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
create_date DATE,
create_ts TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
work_time TIME,
gap INTERVAL
);

INSERT INTO fg_user.t_datatype_time(create_date,work_time,gap)
VALUES(‘2026‑01‑01′,’08:30:00′,’30 days’);

SELECT * FROM fg_user.t_datatype_time;
“`

### 6.4 JSONB实战与索引创建

“`
CREATE TABLE fg_user.t_datatype_json(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
ext_info JSONB
);

INSERT INTO fg_user.t_datatype_json(ext_info)
VALUES(‘{“level”:5,”tags”:[“vip”,”gold”],”contact”:{“mobile”:”13800138000″}}’::jsonb);

–jsonb查询操作
SELECT ext_info ->> ‘level’ AS level FROM fg_user.t_datatype_json;

–创建GIN索引，加速jsonb内部键值查询
CREATE INDEX idx_t_json_ext ON fg_user.t_datatype_json USING GIN(ext_info);
“`

>
> 网上搜索风哥教程可以学习全套数据库教程

## 七、生产数据库设计规范

### 7.1 对象命名规范

1. 全部对象使用小写字母，下划线分隔，禁止大写，避免双引号标识符；
2. 表名建议模块前缀，例如`fg_user.t_user`；禁止关键字作为表名字段名；
3. 主键统一命名id；外键字段建议`xxx_id`；时间字段统一`create_time/update_time`；
4. schema命名业务含义清晰，不要使用数字无意义命名。

### 7.2 字段数据类型选型规范

1. ID主键统一BIGINT，优先`GENERATED ALWAYS AS IDENTITY`；
2. 金额财务字段必须NUMERIC(p,s)，禁止float、double；
3. 文本优先text，长度限制使用CHECK约束；char(n)仅固定长度编码使用；
4. 时间戳业务优先TIMESTAMPTZ，不要使用timestamp不带时区；
5. JSON业务查询场景必须jsonb，原始报文归档才考虑json；
6. IP地址优先inet/cidr类型，不使用text存储IP。

### 7.3 约束使用规范

1. 业务表必须设置主键；
2. 业务逻辑非空字段设置NOT NULL，不要大量依赖NULL；
3. 业务唯一业务编码设置UNIQUE约束；
4. 数值范围校验使用CHECK约束，把业务规则下沉数据库层；
5. 外键根据业务权衡，高吞吐写业务可以放弃外键，应用层保证参照完整性。

### 7.4 schema划分规范

1. 禁止全部业务表堆积在public；
2. 微服务模式：一个database，不同微服务分配独立schema；
3. 多租户模式：根据规模选择schema‑per‑tenant或者行级租户id；
4. 归档历史数据放入独立archive schema，便于运维、备份、权限隔离。

### 7.5 字符集与Locale上线规范

1. 生产数据库编码强制UTF‑8；
2. 互联网业务优先`LC_COLLATE=’C’ LC_CTYPE=’C’`；业务需要中文拼音排序，操作系统必须预先安装对应locale包；
3. 创建数据库必须使用TEMPLATE template0；
4. 上线前校验`pg_database`确认collate与ctype，一旦建库不可原地修改。

### 7.6 常见反模式（避坑清单）

1. 使用char(n)存储普通可变字符串，产生隐形空格；
2. 金额字段使用浮点类型，发生精度丢失；
3. 时间字段使用timestamp不带时区，多时区业务时间错乱；
4. 全部业务表放在public schema，权限混乱；
5. 建库使用template1模板，继承模板库多余对象；
6. json类型代替jsonb做业务查询，无索引性能差。

>
> 上51CTO搜索风哥可以学习全套数据库教程

## 八、综合业务案例演练

完整业务DDL，模拟用户与订单业务，部署于`fgedudb`数据库。

“`
–切换业务库
\c fgedudb

–创建schema
CREATE SCHEMA IF NOT EXISTS fg_biz_user;
CREATE SCHEMA IF NOT EXISTS fg_biz_order;

–授予业务账号权限
GRANT USAGE,CREATE ON SCHEMA fg_biz_user TO fgedu;
GRANT USAGE,CREATE ON SCHEMA fg_biz_order TO fgedu;

–用户业务表
CREATE TABLE fg_biz_user.t_biz_user(
id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
username TEXT NOT NULL CHECK(LENGTH(username)>=1 AND LENGTH(username)<=64),
mobile TEXT,
register_ip INET,
ext_json JSONB,
is_valid BOOLEAN DEFAULT true,
create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_bizuser_mobile ON fg_biz_user.t_biz_user(mobile);
CREATE INDEX idx_bizuser_ext ON fg_biz_user.t_biz_user USING GIN(ext_json);

–订单业务表
CREATE TABLE fg_biz_order.t_biz_order(
order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
user_id BIGINT NOT NULL,
order_sn TEXT NOT NULL UNIQUE,
total_amount NUMERIC(14,2) NOT NULL CHECK(total_amount>=0),
order_status SMALLINT NOT NULL,
create_time TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY(user_id) REFERENCES fg_biz_user.t_biz_user(id)
);
CREATE INDEX idx_bizorder_uid ON fg_biz_order.t_biz_order(user_id);
CREATE INDEX idx_bizorder_ctime ON fg_biz_order.t_biz_order(create_time);
“`

### 表结构简易巡检脚本os_pg_check_ddl.sh，存放路径`/fgedudb/script/os_pg_check_ddl.sh`

“`
#!/bin/bash
echo “========表结构设计巡检 $(date)========”
PGDATABASE=fgedudb
PGUSER=postgres
#列出全部业务表
psql -U ${PGUSER} -d ${PGDATABASE} -t -c “\dt fg_biz_*.*”
#检查缺少主键的表
psql -U ${PGUSER} -d ${PGDATABASE} <<EOF
SELECT nspname AS schemaname,relname AS tablename
FROM pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE c.relkind=’r’ AND nspname LIKE ‘fg_biz_%’
AND NOT EXISTS (SELECT 1 FROM pg_constraint con WHERE con.conrelid=c.oid AND con.contype=’p’);
EOF
echo “========巡检结束========”
“`

脚本执行授权运行：

“`
mkdir -p /fgedudb/script
chmod +x /fgedudb/script/os_pg_check_ddl.sh
/fgedudb/script/os_pg_check_ddl.sh
“`

## 风哥针对本文总结

风哥教程本文完整讲解PostgreSQL数据库对象设计、字符集本地化、schema管理、数据表约束、全系列数据类型选型以及生产落地规范。数据库设计属于上游环节，很多参数与属性一旦创建完成就不可原地修改，比如数据库LC_COLLATE与LC_CTYPE，一旦上线发现错误，只能重建数据库迁移数据，修复代价巨大。

两台标准化主机`fgedu‑net‑cn1`、`fgedu‑net‑cn2`实操案例，全部DDL、DML脚本都可以直接复现执行。核心关键点汇总：

1. 分清实例cluster、database、schema三层对象层级；优先单database，业务模块通过schema做隔离，避免大量database带来运维负担；
2. 字符集务必选择UTF‑8；互联网业务优先`C` locale；业务需要中文拼音排序要预先确认操作系统locale包是否完整，建库使用template0模板；
3. 字段选型：ID主键使用BIGINT GENERATED ALWAYS AS IDENTITY；金额财务必须NUMERIC；时间优先TIMESTAMPTZ；文本优先text；JSON查询业务必须使用jsonb；
4. 约束不要滥用，主键、非空、check、unique根据业务合理配置；外键高吞吐场景权衡利弊；
5. 生产环境禁止业务对象全部堆积到public schema；做好schema划分与账号权限管控；
6. 上线前执行巡检，检查表缺少主键、字段类型不合理、字符集排序规则等风险项，把问题拦截在上线之前。