Database design 在表中存储指向另一个表中的行的指针，而不是使用外键

我只是好奇，是否可以只使用c/java/等方式的指针，而不是基于外键连接表。既然我们在讨论这个话题，postgres或任何其他RDBMS在连接时是否使用指针来快速定位外键引用的行，而不是在包含FKs的整个表中搜索？

数据关系模型的一个基本特征是它不使用指针，数据库外部逻辑视图中的结构链接或基于地址的数据访问。废除指针的使用实际上是Codd在1969年发明关系模型的主要动机之一

---

指针当然是大多数基于关系/SQL的DBMS内部使用的。

Oracle有一种称为ROWID的东西，它将一行的物理地址存储在表中。它们看起来像

AAAA8mAALAAAAQkAAA

，可以细分为：

• 数据对象编号（段）

  [AAAA8m]

• 表空间中的数据文件

  [AAL]

• 数据块（在数据文件中）

  [AAAAQk]

• 行（在块内）

  [AAA]

使用rowid是在单个块读取中物理定位任何行的最快方法。它们在内部使用，但可以由开发人员直接使用。通过主键查找一行，将导致一次（或几次）索引读取以查找rowid，然后数据库将定位该块并提取该行。如果知道rowid，则不需要索引查找

话虽如此，关系数据库的支柱之一是模型应该独立于物理存储（无指针）。此外，它还支持（dbms的）特定实现透明地优化和提供附加功能

每次你使用一只独角兽，一只独角兽就会死去，大便从天上掉下来。例如，如果收缩表，或更新分区表（导致行移动到另一个分区），或正在重建表，或导出/导入表，或。。。或或rowid将更改

---

总之：与常规索引访问相比，基于rowid的访问没有提供足够的好处，不值得冒不可避免的失败风险。知道它们的存在和它们是什么，但永远不要依赖它们。

我经常想知道这一点。RDBMS可以将物理行指针（如PostgreSQL ctid）与外键列中的值一起秘密存储，然后可以使用它查找引用的行，而无需通过索引。但是，每当引用的表被压缩时，它都需要更新。而且，行会更大，因此IO带宽和缓存会更紧张。是否会有净绩效收益？它能证明增加的复杂性吗？但它们是以这种特殊的方式使用的吗？是否有数据库存储指向磁盘上引用行的指针？