プライマリキーとしての文字列データ型と数値データ型

リレーショナルデータベースのプライマリキーの選択に関するこのシリーズへようこそ。パート1では、ナチュラルプライマリキーとサロゲートプライマリキーについて説明し、どちらか一方を選択する理由を検討しました。今回の記事では、プライマリキーとしての文字列と数値のデータ型について調べ、どちらが好ましいのかを確認します。

リレーショナルデータベースの文字列データ型と数値データ型

文字列と数値の命名法はどちらも、実際にはいくつかの異なるデータ型をカプセル化する包括的な用語です。まず、文字列データ型は一般的なIT用語であり、伝統的に一連の文字をリテラル定数または何らかの変数として参照します。データベースに関しては、CHAR型で表される単一の文字もStringでグループ化されます。その他のDB文字列データ型には、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM、SETなどがあります。数値データ型には、INTEGER、SMALLINT、DECIMAL、NUMERICなどの正確な数値データ型と、FLOAT、REAL、DOUBLE PRECISIONなどの近似数値データ型の両方が含まれます。

大論争

プライマリキー（PK）に最適なデータ型に関するアドバイスは、インターネット上にあふれています。数値キーがほとんどの場合に文字ベースのキーよりも優れていると明言しているサイトもありますが、同じ数のサイトが文字列型の使用を促進しています。一方、DBベンダー自身は、どちらのタイプを優先するかを提案しません。彼らが提供するのは、PRIMARY KEY制約に関する指示です。テーブル内の各レコードを一意に識別し、次のことを仮定します：

• プライマリキーにはUNIQUE値を含める必要があり、NULL値を含めることはできません。
• テーブルはプライマリキーを1つだけ持つことができます。テーブルでは、このプライマリキーは1つまたは複数の列（フィールド）で構成できます。
• PKの値は経時的に変更されるべきではありません。

PKが上記の基準を満たしているならば、データベースベンダーに関する限り、問題ありません。しかし、これは、1つの型が他の型よりも優れているという意味ではありません。それらについて詳しく見ていきましょう。

数値型に賛成

データベース開発について初めて学習した時、PKには数値型が最適であると教えられました。この意見は、サロゲートキーを追加することを意味する場合でも、数値PKを使用した私の最初の雇用主である連邦政府によって強化されました。

その意見を反映した評判の良い参考サイトはたくさんあります。MySQLについて言えば、Mysqltutorial.orgが次のように述べています：

MySQLは整数の方が高速に動作するため、プライマリキー列のデータ型は整数（INT、BIGINT など）にするべきです。また、プライマリキーの整数型の値の範囲が、テーブルに含まれる可能性のある全ての行を格納するのに十分であることを確認する必要があります。

数値データの処理に関しては、MySQLは決してユニークではありません。Oracleのプライマリキーに関する別のページには、「Oracleは通常、数値を他のどのデータ型よりも高速に処理するため、プライマリキーは通常数値である」と記載されています。

彼らは、PKデータは「無意味」であるべきだとまで言っています：

時々、社会保障番号（SSN）、車両識別番号（VIN）、電子メール、電話番号などのプライマリキーに、一意であると見なされる意味のあるデータを使用したい場合があります。ただし、メールや電話番号がいつ変更されたり、別の人に再利用されたりするかはわかりません。このような場合、多くのデータの問題が発生します。データベースの世界では、人工的なキーは、ナチュラルプライマリキーとは対照的に、サロゲートキーとして知られています。

来週は...

これまでのところ、数値プライマリキーが最適であるように思われます。ただし、文字列を支持する側からはまだ聞いていません。おそらく、彼らは、代わりに文字列を使用するためのいくつかの非常に正当な理由を提供できます。