ウイザードに大切なこと 本文へジャンプ
ここまでで、想ふこと。

Ruby on RailsでPKが複合キーの場合の対処を書きましたが、基本的にはRuby on Rails本体は複合キーはサポート外なので、もし受託開発であれば当対処は適用するのは難しいですよね。

複合キーというのは、業務システムでは珍しいことではないと思うのですが、サポート外というのはどういうことなのでしょう。

例えば、受発注システムでのお約束のDBテーブルとして、「伝票テーブル」と「伝票明細テーブル」というのがあると思います。

この2つのテーブルは親子関係であり、
「伝票テーブル」のPKは「伝票番号」
「伝票明細テーブル」のPKは複合キーで「伝票番号、明細番号」
リレーションキーは「伝票番号」
というのがありがちなものと思います(さらにいうと「伝票番号」は単純な通番ではなく、伝票の種別的な情報を埋め込む場合もあると思います)。

Ruby on Railsの考え方では、多分ですが、業務的に意味ある列(「伝票番号」「明細番号」)をPKにせず、Rails用の「id」列を設けてPKとするDB設計を想定しているのでしょう。

しかし、ある程度の規模になれば、伝票系のテーブルのレコード数は数百万件レベル以上になると思われ、そうなると、1つの列の追加(この場合、「伝票番号」「明細番号」にもインデックスをはることになるので、その分も含めて)はストレージの設計にも影響が出ると思われます。

極論ですが、Ruby on Railsを使うためのディスク容量は、Ruby on Railsを使わない場合と比較して、増量する可能性もあり、当然設備投資費用も増えます。

速度的な問題だけでなく、この辺についてもRuby on Railsは小規模システムの開発向けなのだろうなあと思いました。

また、レールをはずれたことをやった場合、想像以上に生産性が落ちることがわかりました。

まあ、戯れはこの辺にして、今後は、規約に沿った形で典型的なWebアプリケーションの構築を進めていきたいと思います。