質問: テーブル作成する際、これまで何も考えずidカラム( AUTO_INCREMENT)を作成してきましたが、「レコードに一意な値が必ず入る場合には、必ずしもidカラム( AUTO_INCREMENT)を作成する必要はないかも」、とふと疑問に思ったので質問します。レコードに一意な値が必ず入る場合でも、idカラム( AUTO_INCREMENT)を作成する方が良いですか? --- レコードに一意な値が必ず入るカラム(url)が1つあります。 この時、下記案に違いはありますか? * 案1.idカラム( AUTO_INCREMENT)を作成 * 案2.idカラム( AUTO_INCREMENT)を作成せず、urlカラムに「主キー」もしくは「インデックス」を指定 --- 「主キー」もしくは「インデックス」を指定する場合、id(int型)ではなく、 VARCHAR 型の ようにデータ型が長いカラムを指定すると、処理が速くなる可能性はありますか? データ型が長いカラムを「主キー」もしくは「インデックス」を指定すると、それだけ作成される容量が大きくなる?
回答: テーブルのフィールドが、 ・ユニークで ・nullが入らず ・行が識別可能 であれば、それは主キーとして認められて良いでしょう 特に「行が識別可能」というのがポイントです。 単純に、検索しやすい、見やすい英数字であることに加えて、主キーは外部キーとして利用されることもありますので、アプリケーション的にそのような作りはないか?外部キーとして利用するならば更新があったときに、合わせて修正する対象ではないか?といったことを考える必要があります。 Auto_incrementを用いた主キーの設定というのは、あくまでテーブルのフィールドに上の条件がないときに利用する「疑似キー」などと呼ばれるものです。テーブル上に上記の条件があるならば自然にそのキーを主キーにするべきでしょう。(自然キーとも呼ばれます) もちろんフレームワークの規約上idをつけなければだめだというものもありますのでそれは従うべきでしょう。しかしながら、何でもかんでもidをつけるというのは考えてみてはいかがでしょう? またVARCHAR型とINT型のインデックスはどちらが速度と容量においてどちらが優れていますか質問では、 正直に申し上げると個人的には誤差の範囲内だと思います。 よっぽど大量のデータを入れて、更にギリギリのスペックを要求されているのなら気をつけるべきかもしれないですが、あまりそのような厳しい非機能要件を突きつけられていないなら気にしなくて良いかなと言う印象です。