- ベストアンサー
複雑なクエリの自己結合について
- 複雑なクエリの自己結合について説明します。自己結合を行う際にクエリが複雑になる場合、負荷を少なくする方法について考えます。
- 自己結合を行いたいクエリが相関サブクエリを使用しているため、Viewが作成できない場合、クエリをスマートに自己結合する方法を模索します。
- また、初めに自己結合や外部結合でデータを展開し、それを相関サブクエリなどで絞り込む手法も考えられます。質問者はこの方法が正しいのか迷っており、アドバイスを求めています。
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
データの結合は相乗的にデータが増えるので、自己結合などで 条件設定を冗長にやっていると処理時間が膨大になったり メモリを食い過ぎたりなど当然想定しなくてはいけませんね ＞独学で、1，2か月 で、このレベルの質問ができるとすると、相当基礎的なスキルがあるかとは 思いますが、まずはSQLの基本である正規化について知識を深めて、 インデックスなどをためしながらexplainでテストしていく というのが流れになると思います。 また簡易なデータ参照についてはエンジンも思い切ってMyISAMなどで 処理することで高速化をはかるとか、データ更新がおおくなかったり 完全なリアルタイム性が必要でないものは中間テーブルをつくって 高速化することはできるかと思います。 プロジェクト管理についてはガントチャートやパートチャートの考え方を理解し、 プロジェクトのパートごとに人月設定をしたうえで、アサインするユーザーに 配分の係数を掛けていくと進捗がだせると思いますので プロジェクトテーブル、ユーザーテーブル、プロジェクト＝ユーザーアサインテーブル などに分けて処理すれば効率的にいけるかもしれません。 期間の処理はプロジェクトに寄せるか、さらに別テーブルで管理するかは 出力したい帳票によりますね
その他の回答 (1)
- SherlockHolmes2
- ベストアンサー率40% (175/429)
MySQLはサブクエリに弱いという話を良く聞きます。 ※参考URLを貼っておきます。 私の場合、複雑な処理を書く場合は、後でメンテナンスする人の事も考えてなるべくシンプルに書く努力をします。 複雑なSQL文を使って一発で答えを得るより、簡素なSQLを複数回実行させたほうが、見た目にもキレイになるし、 後でのメンテナンスも楽になると思っているからです。 すみません、回答になっていないかも知れませんが・・・。
お礼
早速の回答ありがとうございます。 >>MySQLはサブクエリに弱い indexの取り方がところどころおかしいとも聞きます、それも関係するのでしょうか。 webの評価を見ている限りフリーでは最強だと思うのですが、商用DBも考えたほうがいいのか。 >>後でメンテナンスする人の事も考え、なるべくシンプルに書く努力 >>複雑なSQL文を使って一発で答えを得るより、簡素なSQLを複数回実行させたほうが、見た目にもキレイになるし、後でのメンテナンスも楽になると思っているからです。 耳が痛いですｗ自分用に、ここまで集合を広げ、こういった特性関数で絞り込むみたいな設計で可視化は やってますが、後の人ことは考えてないです、精進します。
お礼
回答、そしてアドバイスありがとうございます。 >>完全なリアルタイム性が必要でないものは中間テーブルをつくって高速化 やっぱりそれしかないのですかね、テーブルを全更新しているとスピードが使用に耐えないので（explainでテストしてみるべきですけど） トリガつけて差分更新かぁ、そうするとデータの整合性が心配になってくるから、どこでどんなチェックをいれればいいのかなー。それに、メモリ制約結構外れて、汎用性あげられるよな、設計見直さな。むしろ仕様から変更したほうがいいのか？ みたいな 全行程を自分一人でやる（さらに使用者（のうちの一人）も、保守も、利益を得るのも自分）特有の悩みが。むしろ贅沢な悩みかもしれませんがｗ 抜本的な仕様変更も視野に入れ考えてみます。 あと、ガントチャートいいですよね。 プロジェクトといっても少人数で、そんな複雑じゃなく、むしろ複数同時進行で、突発的に予定が入る という仕様上ガントチャートは考えておりませんでした、が余力があれば、インターフェース兼出力帳票として検討してみたいと思います。夢がひろがります、また、仕様が変わりそうですが。