テーブル設計をする際に「プライマリーキーは上のほうに」「同じ種類の情報はまとめて」と、なんとなく暗黙のルールに則っていると安心するし、保守性も上がる。
そして保守期間に入りテーブルのカラムを増やす必要が出たときも同じようにしたいと思うのは、ごく自然な欲求だろう。
MySQL などは After 句があるので、任意の場所に新しいカラムを追加できるが、それがない RDBMS の場合は次のような手順を踏む必要がある。
・最終的に理想とするテーブルを、新しい別名テーブルとして作成する。
・古いテーブルをリネームする。
・作成した別名テーブルを、古いテーブルの元の名前にリネームする。
・他のテーブルから古いテーブルを参照している制約などを外す。
・作成したテーブルに主キー、外部キー、コメントなどを付与する。
・古いテーブルから新しいテーブルに Insert & Select を使ってデータを移す。
・古いテーブルを参照していた制約を付け直す。
・動作確認が終わったら古いテーブルを削除する。
などなど。意外と、とても手間がかかる。
カラムの順序は RDBMS において、なんら影響はなく、Select 文で任意の順に取り出すことができるし、Insert も Update も同様である。そのため、「このような手間をかける意味は何もない」という人もいる。
しかしながら RDBMS や、それを使ったシステムは長い時間と多くの人手をかけて保守されていくものだ。そのときカラムの順序が「なんとなく」でもルールに則っていると、設計者の意図やシステムの構造を理解するのに敷居が低くなることは確実だ。手間をかける意味は十分にあると私は考える。時間が許せばという条件はつくが。
「ドキュメントがあればよい」という人もいるかもしれないが、残念ながら有用なドキュメントが残っているシステムを担当する幸運には、ついぞ恵まれたことがない。しかし経験上、良いドキュメントよりも良いシステム構造の方が、エンジニアにはうれしい。
その他気を付けるべきことは、"Select * ..." や "Insert Into ... Select * ..." などとして利用している場合に、思わぬ副作用が出るかもしれないということだが、そもそもカラムを増やす時点でそれは当然調査しておくべきことなので、あまり大きな問題ではないかもしれない。