データベース(テーブル)を設計する際、レコードの識別を行うカラムにオートインクリメント型を使用することがあります。この属性を使用するとレコードを追加するだけで自動的に一意な値をセットしてくれるので便利です。

しかし、この属性を安易に使用した場合、基幹系システムの構築や運用時にビジネス要件を満たせなかったり、データベース構造が破たんする可能性があります。

オートインクリメント型は自動で値がセットされる代わり、"基本的に"任意の値をセットできない※というデメリットがあります。任意の値をセットできないということは、例えば「社員番号を割り振る際、非正規社員のコードは9で始まるIDにしよう」とか「商品コードの頭二桁は分類が一目でわかる文字にしよう」とか「取引先IDは旧システムのIDを再利用しよう」などといった既存のビジネス要件を満たせないことになります。

もう一つのデメリットとして、このオートインクリメント型で採番された値を他のテーブルとのリレーションに使用すると、オートインクリメントによって"安易に振られたID"が参照側に残ることになるので、万が一障害が発生して被参照側データを削除したり追加した場合、新たなIDが振られてリンクが切れてしまうという事態になります。

つまり、オートインクリメント型を採用しても問題ないケースは、"使い捨て"のユニークIDをレコードに振りたい場合に限ると言ってもいいと思います。

いま流行のフレームワークを使用すると、テーブル作成時にデフォルトでオートインクリメント型のカラムが作成されることがあるそうですが、本来基幹系システムの開発では「ID(コード)設計」というのが一つのタスクになるくらい重要なプロセスになりますので、ビジネス要件と照らし合わせてリレーションに使用できる"キー"となりうるかを十分評価してから採用する必要があります。

※不可能ではありませんが、危うい設計になるので通常ケースでは設計に織り込みません。