外部キーを使用するのではなく、別のテーブルの行にテーブルポインタを格納する

Question

c/java/etcなどのポインタを使用することができるかどうか不思議です。外部キーに基づいてテーブルを結合するのではなく、このトピックでは、Postgresやその他のRDBMSは、結合するときにFKを含むテーブル全体を検索するのではなく、外部キーが参照する行をすばやく見つけるためにポインタを使用していますか？

Answer 1

データのリレーショナルモデルの本質的な特徴は、データベースの外部の論理ビューでポインタ、構造リンク、またはアドレスベースのデータアクセスを使用しないことです。実際、ポインターの使用を廃止したのは、1969年にリレーショナルモデルを発明した主な動機の1つでした。

もちろん、ほとんどのリレーショナル/ SQLベースのDBMSではポインタが内部的に使用されています。

Answer 2

Oracleには、テーブルの行の物理アドレスを格納するROWIDという名前があります。 [AAL]表領域に

• データオブジェクトNR（セグメント）[AAAA8m]
• データファイル
• データブロック（データファイル内）[AAAAQk]
• 行：彼らはに分けることができるAAAA8mAALAAAAQkAAAようになり（ブロック内）[AAA]

rowidを使用すると、物理的にシングルブロック読み出し。それらは内部的に使用されますが、開発者が直接使用することができます。主キーで行を検索すると、1つ（または少数）の索引読み込みが発生してROWIDが検索され、データベースによってブロックが検索され、行が抽出されます。 ROWIDを知っている場合、索引ルックアップは必要ありません。言い換えれば、リレーショナルデータベースの柱の1つは、モデルが物理ストレージ（ポインタなし）から独立していると考えられるということです。また、特定の実装（dbmsの）が追加機能を透過的に最適化して提供できるようにします。

あなたがROWIDを使用するたびに、Unicornが死亡し、糞が天から落ちます。たとえば、テーブルを縮小したり、パーティション化されたテーブルを更新したり（行を別のパーティションに移動させる場合）、またはテーブルを再構築する場合、またはテーブルをエクスポート/インポートする場合、または...または... ROWIDが変更されます。

結論：ROWIDベースのアクセスは、必然的に失敗するリスクがあるため、通常の索引アクセスよりも十分な利点を提供しません。彼らが存在していることと彼らが何であるかを知ってはいますが、それらに頼ることはありません。