アクティブレコードを始めたばかりです。リクエストで複数のクエリを作成しているかどうか疑問に思っていますが、ストアドプロシージャを使用する方がよいでしょうか? そのようにして、複数ではなく 1 つの SQL クエリを作成しています。
たとえば、多くの場合、レコードが存在するかどうかを確認し、存在しない場合は作成します。それは2つのクエリです。クエリを 1 つだけ作成するストアド プロシージャでそれを使用できます。それはパフォーマンスを向上させるための方法ですか?
ありがとう
アクティブレコードを始めたばかりです。リクエストで複数のクエリを作成しているかどうか疑問に思っていますが、ストアドプロシージャを使用する方がよいでしょうか? そのようにして、複数ではなく 1 つの SQL クエリを作成しています。
たとえば、多くの場合、レコードが存在するかどうかを確認し、存在しない場合は作成します。それは2つのクエリです。クエリを 1 つだけ作成するストアド プロシージャでそれを使用できます。それはパフォーマンスを向上させるための方法ですか?
ありがとう
たとえば、多くの場合、レコードが存在するかどうかを確認し、存在しない場合は作成します。それは2つのクエリです。
DBA は、おそらく次のようにアドバイスするでしょう。
重複行の挿入によって発生するエラーをトラップします。
これらはすべて、データベースへのラウンドトリップが 1 回だけ必要です。とにかくエラーをトラップする必要があります。キーの重複以外にも、INSERT ステートメントの成功を妨げる要因はたくさんあります。
一方、一連の SQL ステートメントを実際に必要とするビジネス プロセスがある場合は、おそらくストアド プロシージャを作成するのが理にかなっています。それは、「複数ではなく 1 つの SQL クエリを作成している」ということとはまったく同じではありません。一連の SQL ステートメントを実行する必要があります。サーバーに渡すものは少なくなりますが、それはおそらく重要ではありません。サーバーは引き続きすべての SQL ステートメントを実行します。
このレベルのパフォーマンス チューニングを気にするかどうかはわかりません。
単一行の挿入、更新、削除などに関する限り、適切なインデックスが配置されている場合、データベースのパフォーマンスは、Ruby、クライアントでの DOM 処理、ネットワーク時間などと比較して、パフォーマンス上の問題は非常に小さい可能性があります。 ..数ミリ秒節約できるかもしれませんが、それが重要である可能性は低いです。
以下を使用すると、時間を節約できます。
Model.where(:blah => etc).first_or_initialize(:whatever => 'wotsit')
...後で重大なパフォーマンスの問題を心配できるようにします。
パフォーマンスの向上は、ストアド プロシージャがコンパイルされたままになり、実行計画が保存されたままになるという事実によって得られます。アプリケーションからクエリを作成し、それらがほとんどない場合は、おそらくそうではありません。
タイピングに関しては、場所が違うだけでほぼ同じ量です。