MySQLコミュのTABLEのJOIN、いくつまで許す？

TABLEのJOINは、幾つまでなら許せますか？という愚問です。
結合の仕方やTABLEの設計に左右されるので、当然ケース・バイ・ケースなので、

---------------------------------------------------------------------
『テーブルの結合は○○個までとする』
とコーディング規約に載せるとしたら、

a. 3つまで
b. 4つまで
c. 5つまで
d. 制限(推奨)はしない
e. 結合は絶対許さない
---------------------------------------------------------------------

というお題にしたいと思います。

大抵のコーディング規約には、記載しますよね？遵守されるかは別として。
皆様の経験とさじ加減で、投票をお願いします。

コメント(14)

最初
全て
最新の40件

[2] mixiユーザー 03月04日 00:31

コーディング規約とテーブル設計は別物だと思いますし、制限する理由もよく分かりません。
作りやすい(保守しやすい)様に作るのが一番かと。

[3] mixiユーザー 03月04日 01:08

参考までに：
以前に私が参加したプロジェクト(結構大規模なやつ）では３つまでという制限が付いてました。
それ以上はDB担当のチームにご相談と、DBアクセスのアプリ用のドキュメントに記載されていました。
# まぁ、MySQLじゃなくてDB2でしたけど

なので、非正規化なんてざらで、１００列超えるテーブルがあったのを記憶しています。

[4] mixiユーザー 03月04日 01:12

TABLEをJOINすることで著しくパフォーマンスが低下する危険があるためいたずらに結合するのは避ける、という認識について皆さんの考えを聞いてみたかったので、ちょっと設問を変えたものも追加します。

---------------------------------------------------------------------
インデックスが適切に貼られていた場合に、結合する必要のあるテーブル数、
かつ、結合してパフォーマンスに問題が起こらないテーブル数は、経験上最大

A. 3つまで
B. 4つまで
C. 5つまで
D. もっと沢山結合して、問題は起こらなかった
E. 結合は絶対許さない

---------------------------------------------------------------------

アルファベット大文字にしました。
アルファベット小文字、大文字、どちらについてでも結構ですので投票をおねがいします。

[7] mixiユーザー 03月04日 01:34

＞さ～ぶさん
そういう意味ですと、先ほどの例ではINDEXが適切でも、３つまででした。
結合をたくさんするなら、SELECTのSQLをいくつか発行して、アプリの処理としてくっつけろ、と書いてあった気がします。
あと、DB2はホストでした。一部AIXのもありましたけど、制限がきつかったのはホストの方ですね。
おそらく、アプリケーションサーバの方はスケールアウトが負荷分散装置で簡単にできるけど、ホストはCPU足したりしないといけないというのがあって、制限が厳しかったんだと思っています。

＞うさぴょんの育ての親さん
さすがに性能との兼ね合いですね。かなりのトランザクション数だったようで、Java(だったんですが)のコーディングからかなり厳密な規約が存在していました。
(記憶がたしかなら、利用者数は５万人ぐらいだったかな･･･)

全てのSQLのExplainの実施は当たり前、表ロックが発生するようなSQLは間違いなく使用許可が下りませんでした。
# １００行未満のテーブルなんかは除く
INDEXの追加で対応できる場合もありましたが。

[8] mixiユーザー 03月04日 19:59

Oracleなら，ほぼ問題なくdでした．
ただ，MySQLは難しいのかもしれません．

かなりの数のテーブルをjoinするとSQLが大変なので，viewでラッピングしたりしています．

joinを制限されると，結構困るかもしれません．
selectのSQLを分けた場合は，うまく作らないと，SQLの発行回数が増えるため，遅くなりそうです．
とはいえ，非正規化すると，更新が大変ですし，列の依存関係があるので，プログラムの修正もやりにくいです．
ただ，単純なスキーマだったら，非正規化が一番いいソリューションかもしれませんね．

[9] mixiユーザー 03月04日 22:04

今確認したら
MySQL ですが、9つくらい join してる。

せっかく、５系に変えて view 使えるようになったので、書き直さないといけないのですが、そのままになっています。

いばれた話では、ありませんね。^^:

[10] mixiユーザー 03月05日 20:22

経験的には3つまでですね・・。
サブクエリでjoinもたまにしますが。。

[11] mixiユーザー 03月05日 22:22

個人的には、原則aを主張しています。
でも、アプリ側で文字列比較のループをゴリゴリ回すよりは、Index貼ったテーブルをJoinするのもアリと思ってます。
そういう意味ではIndex適切に貼っているという条件下では、cは許容範囲でしょうか…。

[12] mixiユーザー 03月06日 00:38

d. 制限(推奨)はしない

データベースの概念設計では、One Fact One Placeの完全正規化を目指します。物理設計では、アプリケーションの重さ（重要度、頻度など）を考慮して非正規化しています。

名称などを持つ基本（独立）エンティティまでたどる必要のあるテーブルまで参照するには、結合制限を加えることは、データの独立性と整合性をアプリに要求することは酷かなと思います。

[13] mixiユーザー 03月06日 00:50

私の場合はJOINは「d」の制限しない。ですね。
JOINよりもサブクエリの階層を1段回まで、と決めたりします。

JOINとサブクエリが何階層も絡み合ったSQLを
解きほぐしてJOINだけの構成に変えたら5分→5秒になったこととかあります。
当然元のSQLが無駄だらけだったせいなのですが・・・
でもその時はOracleとDB2のマルチだったな。。

[14] mixiユーザー 03月06日 00:55

d.
複雑な帳票を出す時など、名称マスタやViewを交えてのJOINが
どーんとあったりします。
複雑な帳票ならSpecialなパフォーマンスを求められない？だろう
というのもあったりします。
普段のWindows FormsならなるだけJOINしないような設計（
Table&Forms）を心掛けていますけど。

ログインすると、みんなのコメントがもっと見れるよ