私はPostgreSQL派生のDBMS( Citus )で設計しているテーブルの代理キーの必要性を見ています。 OIDで十分でしょうか? bigint
フィールドとシーケンスを作成する代わりにそれらを使用することの欠点はありますか?
[〜#〜] oids [〜#〜]
ドキュメントから http://www.postgresql.org/docs/9.4/static/datatype-oid.html
Oid型は現在、符号なし4バイト整数として実装されています。したがって、大規模なデータベースで、または大きな個別のテーブルでさえ、データベース全体の一意性を提供するには十分な大きさではありません。したがって、ユーザーが作成したテーブルのOID列を主キーとして使用することはお勧めしません。OIDは、システムテーブルへの参照にのみ使用するのが最適です。
bigintとシーケンス
「_a_horse_with no_name」が示唆するように、bigserialを使用します
注意:smallserialとserialは、上記で指定された4バイトのサイズ制限を克服していないようです。おそらく他の誰かがそれに記入することができます。
Smallserial、serial、bigserialのデータ型は真の型ではなく、一意の識別子列を作成するための表記上の便宜にすぎません(他の一部のデータベースでサポートされているAUTO_INCREMENTプロパティと同様)。
http://www.postgresql.org/docs/9.5/static/datatype-numeric.html#DATATYPE-SERIAL
このあたりには、いくつかの誤解があちこちにあります。
非常に古いバージョンのPostgresでは、デフォルトですべての行にOIDが含まれていました。デフォルトはすぐにnotincludeに変更されましたOIDユーザー定義テーブルの列。
Postgres 8.1ドキュメント を引用:
default_with_oids
(boolean
)これは、
CREATE TABLE
とCREATE TABLE AS
のどちらも指定されていない場合に、WITH OIDS
およびWITHOUT OIDS
にOID列を新しく作成したテーブルに含めるかどうかを制御します。また、OIDがSELECT INTO
によって作成されたテーブルに含まれるかどうかも決定します。PostgreSQL 8.1では、default_with_oids
はデフォルトで無効になっています。 PostgreSQLのバージョンでは、デフォルトでオンでした。
大胆な強調鉱山。 @ Shire quoted は何に関連していますが、OIDは、最新のPostgresのPKについても考慮されていません。
@ a_horse(正しく)提案された明白な理由bigserial
(およびserial
)だけが問題ではありません:
bigint
フィールドとシーケンスを作成する代わりにそれらを使用することの欠点はありますか?
大胆な強調が再び私のものです。通常、serial
列(4バイト整数で実装)は、20億( 2^31 - 1 = 2.147.483.647
)を超える行がテーブルの存続期間。