关系型数据库与 PostgreSQL 基石

关系型数据库与 PostgreSQL 基石

要理解 Supabase，首先要理解它脚下的 PostgreSQL。本节用最朴素的方式讲清楚关系型数据库的核心词汇——表、行、列、模式（schema），以及为什么关系型模型如此强大。

什么是关系型数据库

关系型数据库的核心思想是：把数据组织成一张张二维表，并通过表与表之间的关联（关系）来表达现实世界。

想象一张 Excel 表格：它有列（栏目）和行（记录）。关系型数据库的表与之类似，但严格得多——每一列都有明确的数据类型，每一行都遵循预设的规则，表与表之间还能通过共同的字段建立关联。这种「以表为核心、以关系为纽带」的模型，就是「关系型」名称的由来。

表、行、列：三位一体

• 表（Table）：一类数据的集合，比如「用户表」「订单表」。表名通常是复数名词。
• 列（Column / 字段）：表的「栏目」，定义数据的某一类属性，比如用户的「邮箱」「昵称」。每列都有明确的数据类型。
• 行（Row / 记录）：表中的一条具体数据，比如某一个用户、某一笔订单。一行就是各个列取值的一个组合。

举一个例子，用户表 users 可能长这样：

这里 id / email / name / created_at 是列，每一行代表一个具体用户。

模式（Schema）：表的命名空间

随着表越来越多，需要一种方式对它们进行分组管理，这就是模式（schema）。可以把模式理解为「表的文件夹」。一个数据库里可以有多个模式，每个模式里有多张表。

Supabase 项目中，业务数据默认位于名为 public 的公开模式下；而认证系统的用户表等则位于 auth 等专用模式中。日常开发绝大多数时候你只与 public 模式打交道，但知道「模式」这个层级的存在，有助于理解 Supabase 的整体组织。

关系的力量：为什么不是一张大表

初学者常问：为什么不把所有信息塞进一张大表？关系型数据库之所以「分表」，是为了消除冗余、保持一致性。

举个例子：如果把「用户信息」和「订单信息」塞在同一张表里，那么用户的邮箱会随每笔订单重复存储很多次——一旦用户改邮箱，就要更新成百上千行，极易出错。把用户与订单拆成两张表，用「用户 id」关联，则每条用户信息只存一份，改邮箱只需改一行。这就是「关系」带来的价值：通过关联而非重复来表达数据。

为什么选择 PostgreSQL

PostgreSQL 是世界上最成熟、功能最丰富的开源关系型数据库之一，选择它意味着：

• 标准 SQL：支持完整的 SQL 标准语法，学习成本低、可迁移性强。
• 数据类型丰富：除数值、文本、时间外，还原生支持 JSON、数组、UUID、布尔、枚举、地理空间等类型。
• 扩展生态：可通过「扩展」获得向量检索（pgvector）、全文搜索、地理信息等高级能力，Supabase 项目可一键启用。
• ACID 事务：保证多步操作的原子性与一致性，适合金融、订单等关键场景。
• 成熟稳定：历经数十年验证，被众多大型系统采用。

正因为这些特性，Supabase 才把 PostgreSQL 作为整个平台的基石：你学到的表设计、SQL、约束、关系等知识，都是通用且可迁移的，不会随平台绑定而作废。

小结

关系型数据库以「表」为核心组织数据，以「关系」连接表与表，从而避免冗余、保证一致。PostgreSQL 作为其中的佼佼者，提供了丰富的类型与扩展能力，是 Supabase 的根基。理解了这些基石概念，下一节我们就能进入具体的数据类型选择，开始动手设计表结构。