ORマッパーは（中略）テーブル構成が比較的単純に済むWEBアプリを開発するためにはたしかに効果的なのだが、テーブル数がふつうに100個を越える業務システムではむしろ足を引っ張る。
これは妥当な指摘である。
ふつうに設計されたDBでは、少なくとも半数のテーブルが複合主キーをとる。ところが多くの場合、ORマッパーを基礎とする開発環境では、複合主キーの使用が非推奨なのである
確かにActiveRecordは原則的に複合主キーを推奨しない。
その結果、DBに含まれる半数のテーブルについて、通常の設計の他に、ORマッパーに合わせて「正規化崩し」したテーブル定義を管理せざるを得なくなったりする。
人工キー＋単一キーパターンと正規化を崩すことに関連性があるかは疑問である。
もうひとつの弊害として、育成上の悪影響を指摘できる。キャリアの初期にORマッパーを用いた開発を繰り返すことで、新人技術者が「複合主キーなしでDB設計は可能であり、そのほうが合理的である」と勘違いしてしまう怖れがある。
個人的に複合主キーを有するテーブルの方が性に合わないが、それはそれとして、まともなDB設計ができない人間が増えたのは事実であるように思う。
悪いことに、複合主キーを用いた端正なDB設計になかなかお目にかかれないのが実情である。キー項目がいつの間にか増えたり、やたらと多くの項目が無駄に複合されていたりする。そんな設計ばかりに触れていたら、「複合主キーなんてロクなもんじゃない」と感じてしまうのも無理はない。的確にDB設計するために複合主キーは必要だが、稚拙なDB設計にも複合主キーがふつうに現れる。それゆえこれを用いることの意義がなかなか理解されない。
確かに自分が携わったプロジェクトでは見たことがない。無計画に増殖していく複合キーにうんざりさせられることばかりだった。
とはいえ、「複合主キーを使ってDB設計することが難しすぎるから、もう全部idにしてしまおう」などと考えてはいけない。
これはまぁ、確かに。
とはいえ、複合主キーの目指すところはユニーク制約で代替できるのではなかろうか？
ORマッパーがもたらす三つめの弊害。それは、JavaとかRubyといった汎用プログラミング言語で個別案件をナイーブに開発するやり方が是認され、技術革新の足かせになってしまうことだ
（中略）
業務システム開発における汎用プログラミング言語の使いどころは、そこではない。規定様式で仕様を記述するだけ（つまり設計するだけ）で業務システムとして動作してくれるDSP（ドメイン特化プラットフォーム）を作る。そのためにこそ使うべきだ。
どうだろうか。特定のDSL運用基盤に依存することにリスクがあるから、汎用プログラミング言語を使っているのだとは考えられないだろうか。