Skip to Content
帮助文档数据处理概念理解关系型数据库思维

关系型数据库思维

在数据模型与流转中，数据库承担着持久化存储（硬盘）的角色。数据是应用的心脏。在无代码或低代码开发中，要构建功能完备、逻辑严密的商业软件，必须建立清晰的 “关系型数据库思维”。

Zion 的底层数据库基于高性能的企业级关系型数据库 PostgreSQL 构建。本篇将帮助您从零建立数据建模的直觉。

1. 实体与关系型思维

在开始建表之前，您需要将现实业务场景拆解为一个个独立的 “实体” 与它们之间的 “联系”。

  • 实体：指的是客观存在并可以相互区别的事物，在数据库中表现为一张张 “数据表”（如：user、product、post、tag）。
  • 属性：描述实体的具体特征，在数据库中表现为表中的 “字段”（如：product 表的 price、name、stock）。
  • 关系：两个或多个实体之间的业务联系（如：user “购买” product，account “发表” post）。

关系型数据库的精髓在于：用多个高度内聚、结构单一的表来独立表达各实体，通过“主键/外键关联（ID 关联）”来拉通实体间的业务逻辑，避免信息的大量重复冗余。

2. 表间关联关系

在数据世界里，表与表之间的业务联系主要分为以下三种经典类型：

2.1 一对一关联

  • 概念：A 表中的某一行记录，有且仅能与 B 表中的某一行记录相对应；反之亦然。
  • 经典场景：
    • 用户与钱包：一个注册用户（user）只能拥有一个资金钱包（wallet），一个钱包也只能归属于一个特定用户。
    • 用户与详细档案：为了保障主表查询性能，常将敏感或极少使用的详细档案拆分至子表（user_profile），形成一对一关联。
  • 实现机制：系统会自动在其中一张表（通常是子表）中增加一列，用于存放主表的 id，并增加唯一性约束，保证该 id 绝不重复。

2.2 一对多关联

  • 概念：A 表中的单行记录，可以与 B 表中的多行记录相对应；但 B 表中的单行记录，只能与 A 表中的某一行记录相对应。
  • 经典场景：
    • 作者与博客文章：一个账户（account）可以发表多篇博客文章（post）；但任何一篇特定的博客文章，其作者有且仅能有一个。
    • 店铺与商品：一个商家店铺（shop）可以上架数百款商品（product）；但任何一件具体的商品，只能归属于某一家特定店铺。
  • 实现机制：系统会物理地在“多”的一方数据表中，自动新增一列（外键字段），用来保存“一”的一方记录的 id（例如：在 post 表中，自动新增一列 account_id，存放对应的作者 id）。

2.3 多对多关联

  • 概念：A 表中的某行记录可以对应 B 表中的多行记录；同时，B 表中的某行记录也可以对应 A 表中的多行记录。
  • 经典场景：
    • 文章与标签：一篇博客文章（post）可以贴上“AI”、“无代码”等多个标签（tag）；同时，一个标签下也汇聚了成百上千篇不同的文章。
    • 学生与课程：一个学生（student）可以选修多门课程（course），一门课程也会被多名学生同时选修。
  • 实现机制： 在关系型数据库中，不能直接在两张表之间建立多对多物理字段。多对多关联必须通过一张 “中间表” 来作为纽带：
    1. 创建专门的关联纽带中间表（如：post_tag）。
    2. 让 A 表（post）和 B 表（tag）分别向中间表建立 一对多 关联。
    3. 中间表中的每一行记录，都是由“文章 ID”和“标签 ID”组成的键值对。每一行代表了一次绑定关系，从而在物理上完美解耦并拉通了多对多业务。

3. 字段类型与设计规范

在关系型思维中，字段的类型设计直接影响了数据的严谨性和运算效能。Zion 提供了一整套工业级字段类型：

  • 主键 (id)：每张表默认包含且系统自动维护的物理 id。它是每行数据在整个宇宙中的唯一、非空身份标识。
  • 时间度量：系统默认带有的 created_at（创建时间）、updated_at（更新时间）字段（不可修改与删除）。
  • 数值精度：Zion 采用无限精度数值类型（Decimal），以确保财务和业务数据的绝对精确。
    ⚠️

    浮点数精度丢失提醒：
    在纯数据库加工时数据绝对精确。但当数据流经代码块（Node.js JS 引擎）或进行外部 API 浮点运算时，由于 JavaScript 底层统一使用双精度浮点数表示，运算（如 0.1 + 0.2）可能会产生微小误差（如变为 0.30000000000000004）。如若重新写入数据库，可能会保存下该精度丢失后的长小数。设计高精密计算（如账单）时需特别注意。

4. 数据更新与存储原理 (MVCC)

了解数据库的存储机制，有助于您科学规划项目的存储容量和升级预算。

Zion 的关系型数据库底层基于现代企业级 多版本并发控制 (MVCC) 机制：

  • 当您的用户在前端执行修改（UPDATE）或删除（DELETE）数据时，系统并不会直接在磁盘原物理位置上强行擦除或重写。
  • 为了保障高并发事务不锁表、不冲突，系统会将旧数据标记为“过期（不可见）”，并在物理磁盘新位置写入新版本的数据。
  • 物理体积不减反增：由于过期版本仍会占用部分物理空间，在您执行大批量数据修改后，会发现项目的存储占用（数据库膨胀）暂时变大。
  • 自动回收 (VACUUM)：系统部署了全自动的碎片整理垃圾回收器。它会在每日业务波谷期自动检测并释放已过期的物理磁盘空间，这一过程完全静默自动执行，无需开发者任何手动干预。
Last updated on
数据模型与流转变量和参数