2

c/java/etc のポインターを使用することが可能かどうか、ただ興味があります。外部キーに基づいてテーブルを結合する代わりの方法。また、このトピックに取り組んでいるので、postgres やその他の RDBMS は、結合時にポインタを使用して、FK を含むテーブル全体を検索する代わりに、外部キーによって参照される行をすばやく見つけますか?

4

2 に答える 2

3

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

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

于 2011-04-10T10:22:35.380 に答える
1

Oracleには、行の物理アドレスをテーブルに格納するROWIDと呼ばれるものがあります。それらは次のようAAAA8mAALAAAAQkAAAに分類できます。

  • データ オブジェクト番号 (セグメント)[AAAA8m]
  • 表領域のデータファイル[AAL]
  • データ ブロック (データ ファイル内)[AAAAQk]
  • 行 (ブロック内)[AAA]

行 ID を使用することは、1 回のブロック読み取りで任意の行を物理的に特定する最速の方法です。これらは内部で使用されますが、開発者が直接使用できます。主キーで行を検索すると、行 ID を見つけるために 1 回 (または数回) のインデックス読み取りが行われ、データベースはブロックを見つけて行を抽出します。行 ID がわかっている場合は、インデックスの検索は必要ありません。

そうは言っても、リレーショナル データベースの柱の 1 つは、モデルが物理ストレージから独立している (ポインターがない) ことです。また、(dbms の) 特定の実装を最適化し、追加機能を透過的に提供できるようにします。

Rowid を使用するたびに、Unicorn が死亡し、うんちが天から降ってきます。たとえば、テーブルを縮小する場合、またはパーティション化されたテーブルを更新する (行を別のパーティションに移動させる) 場合、テーブルを再構築する場合、またはテーブルをエクスポート/インポートする場合、または... または... または.. . 行 ID が変更されます。

結論として、rowid ベースのアクセスは、通常のインデックス付きアクセスよりも、避けられない失敗のリスクに見合うだけの十分な利点を提供しません。それらが存在し、それらが何であるかを知っていますが、決してそれらに依存しないでください.

于 2011-04-10T11:48:13.420 に答える