質問: お世話になります。 カラム数が200を超えるテーブルを複数扱う案件を受け持ちました。 実際のテーブル情報などは載せれないので似た例としてゲームの情報を扱うテーブルがあったとします。 今回は簡単ですが、このgenreについてもそれぞれたくさんの情報があると50を超えるカラムがあると考えてください。 ![元のテーブル](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/82a7eb8f65a787f5414e0c529cf43ebb.png) 私が考える構成は以下のようなものです。 ![分割後](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/2bc4660f5364eb45c24b0e7710e129ee.png) game_information_genres、game_information_makersそれぞれにも50を超えるカラムがあるとします。 以下のようにgame_informationsテーブルでまとめなくても良いとは思うのですが、game_information_genres、game_information_makersのデータを一度にまとめて取得したいと言った時に簡単に取得できるので中間テーブル?としてgame_informationsテーブルも設置しました。 ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/4d144a2ffa95d9fbd7d1650bc4648057.png) この構成(2つ目の画像)は良い設計と言えるでしょうか? 私はこの構成だと以下の問題を持つと考えています。 * テーブル名が長くなりすぎる * それに伴って、関連キーのカラム名が長くなりすぎる * SQL実行1回のコストが高くなる しかし、メリットとして * 情報が視覚的に分かりやすくなる * 情報取得コードがシンプルになる(ActiveRecord) * 構成の変更がしやすい もあげれるのではないかと考えています。 非常にカラム数が多くカオスで、今後の保守・開発がスムーズに進むようにもっとも望ましい形にしたいと考えています。 皆様のお力を貸していただきたいです。 どうぞよろしくお願い致します。
回答: 良い設計ではないです。 200を超えるカラム数というのは確かに分割する要素はあるのかもしれませんね。 テーブル設計の変更に対しては、正規化の観点でよりよい設計とならないか検討してみてください。 この時、求められる処理と正規化のレベルに注意してください。それが正しい設計につながります。 良い設計ではないとした理由は、保守・開発がスムーズに進むことを目的としているからです。 yamashoさんにとっては求めている回答と少しずれた回答かもしれませんね。 説明します。 テーブル設計として良否を決定するものは"性能"です。テーブル設計としてカラム数が設計の良否を決定づけるものではありません。システムの利用者にとって性能は絶対的評価基準で、処理が遅いシステムはそれだけで悪とみなされます。データベースはシステムの性能の核になります。テーブル設計は最も性能が出るよう努力されたものであることが求められます。 yamashoさんも「SQL実行1回のコストが高くなる」と性能に悪影響があることは想定されています。これは正しいです。「今後の保守・開発がスムーズに進む」この気持ちすごくわかります。ですが、メリットに書かれた内容に利用者にとってのメリットはあるでしょうか。私には我々開発者がよくやる開発側の論理にに見えました。やってしまった結果性能が落ちトータルで悪い結果につながるオチがつくパターンです。 正規化に取り組んでみてください。もしかしたら結果として200カラムを超えるテーブルが出来上がるかもしれません。もしそうなったら、200カラムを超えるテーブルは正しいテーブル設計であったと言えます。 Railsで実装するにあたって200カラムのレコードなんてと思う気持ちわかります。 が、ORマッピング分野においてこの手の話は最適解がない課題なんですよね。。。 極論的には"この部分だけは"フレームワークのORマッピング(RailsのActiveRecord)は使わず自前のORマッピングを用意して捌くと思います。 yamashoさんの構成イメージにある genre と maker を 200カラムレコードの該当カラム使ってObjectにMappingするORマップ処理を自前で作るイメージです。