第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （2）列持ちテーブル | gihyo.jp

第2回を読まれた方は、この両者を変換するSQLを紹介したことを覚えているでしょう。そのSQLを利用すれば、「⁠列持ち」⇔「行持ち」の変換を行うことが可能なので、最悪、設計時点でどちらかのモデルを選択したあとに、「⁠やはりうまくいかなかった」ということでもう一方のモデルへチェンジすることも、できないわけではありません（アプリケーション側の修正など、相応の工数は覚悟せねばなりませんが⁠）⁠。しかし、最初は可能な限り「行持ち」を選択するべきです。 その理由は、列持ちモデルの拡張性と保守性の低さです。実際、今は2008年なので年度ごとに作られた列も2008年まで用意していればよいとして、来年になったらどうすればよいのでしょう？ 列をもう1つ追加するほかありません。すると毎年テーブルの構造を変えなければなりませんし、このテーブルへアクセスするSELECT文から結果を受け取るホスト言語まで、ほとんどシ

[mumincacao]

列待ちってなにかと思ったら列持ちと混ざってるのです・・・でもこんな構造のて～ぶるときどき見かけるけどやっぱり遠慮したいところだにゃぁ・・・（´・ω・｀；【みかん