用 PostgreSQL 实践 Palantir 本体论

关注

原创最新推荐文章于 2026-11-01 12:44:45 发布 1.4k 阅读 AI 写同款· GEO 优化 ›

用PostgreSQL落地Palantir本体论：轻量级对象数据建模实践数据建模是企业系统架构的核心命题，传统关系型表结构在面对复杂业务语义时往往显得僵硬。本体论作为一种面向对象的数据建模思想，通过对象类型、属性、关系和事件流来描述现实世界，已在工业界大规模智能决策场景中得到验证。PostgreSQL凭借JSONB、视图、递归CTE及触发器，提供了实现轻量级本体层的完整能力。实践者可将对象体系映射为注册表与实例表，利用视图表达派生属性，以事件表支撑状态溯源，并通过函数封装业务动作。这套方案既能保留关系型数据库的查询性能与事务保证，又能获得灵活的模型扩展性，适用于数据中台、业务中阅读详情

作者简介：怀玉杰，瀚高股份研发工程师，负责 AI 方向研发，擅长算法分析与 AI 应用。

医院数据管理的挑战

介绍

当前医院的信息系统呈现出多系统并存的复杂局面。一家三甲医院通常运行着数十个不同的业务系统：HIS（医院信息系统）处理核心业务，EMR（电子病历系统）记录诊疗过程等。并且医院场景本身复杂多变，患者从入院到出院整个过程往往要经历多个阶段：入院登记、床位分配、科室调整、检查与治疗、最终出院。

以床位管理为例，护士寻找空床需要反复在系统查询和电话确认之间切换，效率低下且容易出错。当前主流医院系统设计是状态驱动的建模方式，只记录当前状态，如：在患者表中维护当前状态（在院/出院/转科中），无法追溯历史变化，随着数据增多、业务繁杂，各种问题也逐步暴露。

CREATE TABLE beds ( bed_id uuid DEFAULT gen_random_uuid() NOT NULL, bed_number varchar(100) NOT NULL, department_id uuid NULL, bed_type varchar(20) NULL CHECK (bed_type IN ('普通床', 'ICU床','隔离床', '抢救床','儿科床')), equipments jsonb NULL, current_status varchar(20) NULL CHECK (current_status IN ('占用','空闲','清理中')), physical_location jsonb NULL, support_isolation bool DEFAULT false NULL, specialty_attribute text NULL, created_at timestamptz DEFAULT now() NULL, updated_at timestamptz DEFAULT now() NULL );

当前问题

首先是可追溯性问题。当系统只保留“当前状态”时，无法进行历史追溯、操作追溯，很难回答看似简单的问题：谁用过这张床？病人为什么转科？床位状态为什么是这样？

其次是逻辑分散、维护成本高的问题。技术实现中，每个业务操作需要编写专门的存储过程（procedure），且牵扯多种函数或表关系，当业务规则发生变化时，往往需要同时修改多处代码且新增业务类型时，需要考虑对现有流程的影响。随着业务流程的复杂，会导致系统越来越臃肿，最终复杂的存储过程与触发器会难以理解和调试，成本也会越来越高。

最后是系统语义模糊的问题。在状态驱动模型中，数据库中的一行记录，往往混合了三种含义：现实世界发生过什么；系统当前认为是什么状态；流程执行到了哪一步。这三者在数据层面被耦合在一起，使得系统越来越像一个“黑盒”。

综上所述，医院这种高度依赖时间、行为和约束，且场景多样复杂，行为动态变化的需求下，我们需要新的数据管理思维去建立新的系统。以床位系统为例，需要有以下优点：

完整的历史追溯：能还原床位状态的完整演变过程。
数据一致性：避免多系统间的数据矛盾。
操作透明性：每个状态变化都有明确的上下文记录。
扩展灵活性：新业务能快速上线，不影响现有功能。
分析支持能力：基于历史数据提供决策支持。

因此，我们希望系统能够完整记录整个过程，状态只是从事实中推导出的结果。

Palantir 方法论

方法论简介

Palantir 提出了以 Ontology（本体论）为核心的数据建模方法论，并在复杂业务系统中，将“行为（Action）”而非“状态（State）”放在系统的中心位置。

本体论是一种工程化的数据建模方法，其核心观点是：信息系统不应该关注"状态"，而应该关注"发生了什么"，然后从这些事实中推导出当前状态。

‘行为记录’并不意味着把所有业务逻辑都放在数据库中。相反，本体论倡导清晰的职责分离：应用层负责业务流程的编排和规则执行，而数据库层则专注于忠实地记录这些流程产生的’行为’。这种分离使得系统既能享受行为驱动的追溯能力，又能保持架构的灵活性和可扩展性。

以床位系统为例：本体论不是记录"床位现在是空的"，而是记录"病人 A 于 10:00 从床位 1 出院了"，然后推导出"床位 1 现在是空的"。

在这种模型下，系统的职责不再是不断“修改状态”，而是完整、准确地记录每一次行为的发生。一旦行为被记录下来：状态可以随时重新；计算历史可以完整回放；业务决策可以基于事实进行分析。

对比

我们以患者转科的例子来比较传统思维与 Ontology 的区别：

传统转科思维模式：

更新患者表的状态：

UPDATE patient SET department_id = '心内科' WHERE patient_id = '001';

更新床位表的状态

UPDATE bed SET current_status = '清理中' WHERE bed_id = 'B01';

UPDATE bed SET current_status = '占用' WHERE bed_id = 'B02';

Palantir 思维模式：

在行为表中记录一个不可变的事实

INSERT INTO bed_events ( patient_id, event_type, event_time, details ) VALUES ( '001', '占用', '2024-01-15 14:30:00', '{ "department": "心内科", "bed": "B01", "reason": "确诊冠心病需专科治疗", "doctor": "张明", "order_id": "ORDER_789" }'::JSONB );

自动更新床位的视图

CREATE VIEW current_bed_status AS WITH latest_bed_events AS ( SELECT DISTINCT ON (bed_id) * FROM bed_events ORDER BY bed_id, event_time DESC )

优势

通过上述对比，我们可以总结出以下优势：

业务优势：

完整溯源：能够回答"病人为什么转科"、"床位谁用过"这类历史问题。
数据一致性：所有系统基于相同的事实记录，避免状态不一致。
业务灵活性：新增业务流程只需定义新的事实类型，无需修改现有结构。

技术优势：

系统解耦：事实记录层与业务逻辑层分离。
简化维护：无需复杂的存储过程链，核心逻辑是记录事实。
便于分析：所有历史数据都在，方便进行趋势分析和决策支持。

医院业务的复杂性不仅在于流程多，更在于每个流程都需要完整的溯源能力。无论是医疗质量管理、费用追溯，还是医疗纠纷处理，都需要能够回答"当时发生了什么"。Palantir 的本体论解决了这一问题：不再试图维护一个"完美"的当前状态，而是忠实地记录所有重要事实，让状态成为事实的自然推导结果。

PostgreSQL ：Palantir 思想的天然数据基石

PostgreSQL 的优势

这种思想转变带来了数据管理范式的革新，但要真正落地，我们需要一个能够有效支持这种数据模型的技术平台。在实践中，PostgreSQL 是本体论实现的天然数据基石。

以医院系统为例，有以下契合点：

记录事实：

本体论的核心在于事实优先，而相较于传统数据库，PostgreSQL 在事实型数据建模方面具备天然优势：

JSONB 类型：可存储任意结构的上下文数据，适合事实表的构建，当业务流程变化时，无需频繁修改表结构，只需在 JSONB 中扩展新的字段即可。
时间类型丰富：PostgreSQL 提供了多种时间类型，并支持时区转换，适合精确描述行为发生的完整时间维度。
表继承与分区：通过表继承能自然建立事实表的层级关系，而分区功能可以有效管理海量历史数据，提高查询性能和管理效率。

描述状态：

在本体论中，“状态”是由事实型数据推导的结果，而 PG 在这方面具备显著优势：

视图与物化视图：PostgreSQL 支持复杂的视图和物化视图，可以从事实表中实时推导出当前状态。物化视图支持自动或手动刷新，在性能与实时性之间提供灵活平衡。
窗口函数与聚合：PostgreSQL 拥有强大的窗口函数和聚合能力，能够基于历史事实序列计算出各种状态指标，如平均住院日、床位周转率等。
递归查询支持：通过 CTE（公共表表达式）和递归查询，可以处理复杂的层次结构和时序分析，例如完整追溯患者的整个诊疗过程。

维护数据一致性：

PostgreSQL 提供了多种机制来维护事实数据的质量和一致性：

事务保障：通过 ACID 事务保证事实记录的原子性和一致性，即使在高并发场景下也能确保数据完整。
约束与触发器：丰富的约束类型（检查约束、唯一约束、外键约束）和触发器机制，能够在数据层自动维护数据质量，确保事实记录的准确性。
并发控制：多版本并发控制（MVCC）机制确保在高并发环境下，事实记录的写入和状态查询可以高效并行执行。

特有扩展能力：

PostgreSQL 通过丰富的扩展生态系统，能够满足医疗场景中的特殊需求：

空间数据分析：PostGIS 扩展支持地理空间数据存储与分析，可用于医院床位布局优化、患者动线分析等场景。
外部数据集成：通过 FDW（Foreign Data Wrapper）可以透明地集成医院其他系统的数据，实现真正的数据融合，而无需复杂的 ETL 流程。
时序数据优化：TimescaleDB 扩展专门优化时序数据处理，能够高效管理医院环境中产生的大量时间序列事实数据。
图数据支持：Apache AGE 扩展为 PostgreSQL 增加图数据库能力，可以分析复杂的医患关系、疾病传播路径等。

生态成熟：

PostgreSQL 在生产环境中已经证明了其可靠性和稳定性：

开源可控：开源许可确保医院能够完全掌握核心技术栈，避免厂商锁定风险，同时降低了软件许可成本。
成熟工具链：拥有 pgAdmin、pgBackRest、pgBouncer 等成熟的运维管理工具，覆盖监控、备份、连接管理等关键运维场景。
活跃社区：全球活跃的开源社区和多个商业支持厂商，确保技术问题能够快速响应和解决。
云原生支持：所有主流云平台都提供托管的 PostgreSQL 服务，简化部署和运维。

PostgreSQL 的定位

综合来看，在本体论中，PostgreSQL 承担以下角色：

现实世界行为的事实存储层。
业务状态的推演与分析基础。
多系统数据一致性的核心锚点。

这些特点使 PostgreSQL 作为数据层的坚实基础，成为本体论方法中落地的理想选择。

具体实现

在本文中，我们以医院床位管理为例，设计一个最小的 PostgreSQL Demo，用于验证本体论思路在实际业务场景中的可行性。

本体论视角下核心对象建模

在医院床位管理场景中，主要可以抽象出以下几类核心对象：

Patient
Bed
Department
Order（医嘱表）：表示医生的医嘱，是意图而不是已发生的事实

这些对象本身相对稳定，业务变化不体现在对象结构上，而是体现在它们的关系变化上。

create table beds( bed_id uuid default gen_random_uuid() not null, bed_code varchar(100) not null, department_id uuid null, bed_type varchar(20) null check (bed_type in ('普通床', 'icu床','隔离床', '抢救床','儿科床')), last_changed_at timestamp );

系统中的事实存储

在床位管理场景中，有事实存储表：bed_actions，只负责记录事实，不包含业务逻辑。需要强调的是：

Action 表不包含状态字段。
不区分“执行中 / 已完成 / 已失败”。
一条 Action 一旦写入，即被视为系统确认的事实。

这使得 Action 表天然具备以下特性：

事实不可篡改。
历史完整保留。
行为语义清晰。

create table bed_actions ( action_id uuid primary key default gen_random_uuid(), action_type text not null check( action_type in ('被分配','被释放')), patient_id uuid not null references patients(patient_id), bed_id uuid references beds(bed_id), from_department_id uuid references departments(department_id), to_department_id uuid references departments(department_id), context jsonb, occurred_at timestamptz not null default now() );

使用说明

在这个模型中表达一次转科流程，是两条 action：释放原床和分配新床。

#释放原床 insert into bed_actions( action_type, patient_id, bed_id, from_department_id, context) values( '被释放', 'Patient_01', 'B01', 'D01', jsonb_build_object( 'reason','转科转出', 'order_id':order_id ) ); #分配新床 insert into bed_actions( action_type, patient_id, bed_id, from_department_id, context) values( '被分配', 'Patient_01', 'B02', 'D02', jsonb_build_object( 'reason','转科转入', 'order_id':order_id ) );

若想查询“某科室有哪些空床”，根据 bed_actions 表派生状态，使用 SQL 进行查询。

#构建床位状态表 create view bed_current_status as select b.bed_id, b.department_id, case when last_action.action_type = '被分配' then '占用' when last_action.action_type = '被释放' then '空闲' else '空闲' end as bed_status from beds b left join lateral ( select * from bed_actions a where a.bed_id = b.bed_id order by occurred_at desc limit 1 ) last_action on true; #查询某科室空床 select * from bed_current_status where department_id = :dept_id and bed_status = '空闲';

总结

从状态驱动到行为驱动的转变，本质上是数据管理思维的根本革新。传统系统试图维护一个"完美的当前状态"，而本体论方法选择忠实地记录"所有重要事实"。这种转变让系统具备了前所未有的追溯能力和灵活性。

PostgreSQL 凭借其强大的数据管理能力，成为这一方法落地的理想选择。它不仅提供了技术实现的可能，更重要的是其设计哲学与本体论思想高度一致：都强调数据的完整性、一致性和可追溯性。

在实际应用中，这种架构实现了职责的清晰分离：应用层专注于业务流程编排，PostgreSQL 作为数据基石。 选择 PostgreSQL，并以行为为核心建模时，许多看似复杂的问题——历史追溯、状态一致性、系统可解释性——都会在模型层面被自然化解。数据库不再只是数据的存储容器，而成为对现实世界的结构化表达。这正是本体论方法在复杂业务系统中真正的价值所在。

HOW 2026 议题招募中

2026 年 4 月 27-28 日，由 IvorySQL 社区联合 PGEU（欧洲 PG 社区）、PGAsia（亚洲 PG 社区）共同打造的 HOW 2026（IvorySQL & PostgreSQL 技术峰会）将再度落地济南。届时，PostgreSQL 联合创始人 Bruce Momjian 等顶级大师将亲临现场。

自开启征集以来，HOW 2026 筹备组已感受到来自全球 PostgreSQL 爱好者的澎湃热情。为了确保大会议题的深度与广度，我们诚邀您在 2026 年 2 月 27 日截止日期前，提交您的技术见解。

投递链接：https://jsj.top/f/uebqBc