次のうちどれがより良い選択肢であるかを理解しようとしています:
- MySQL クエリの出力から Python を使用してデータを計算します。
- クエリ自体で計算を実行します。
たとえば、クエリは 10 列の 20 行を返します。Python では、いくつかの列の差または除算を計算します。
クエリまたは Python でこれを行う方が良いですか?
次のうちどれがより良い選択肢であるかを理解しようとしています:
たとえば、クエリは 10 列の 20 行を返します。Python では、いくつかの列の差または除算を計算します。
クエリまたは Python でこれを行う方が良いですか?
行の計算に対して基本的な算術演算を行う場合は、SQL で行います。これにより、結果をビューまたはストアド プロシージャにカプセル化するオプションが提供されます。多くのデータベースでは、ステートメントの並列実行の可能性も提供します (ただし、データ行が非常に少ないため、パフォーマンスは問題になりません)。
MySQL で行間で操作を行っている場合 (列の最大値を取得するなど)、バランスはより均等になります。ほとんどのデータベースはこれらの計算に対する単純な関数をサポートしていますが、MySQL はサポートしていません。クエリが複雑になると、クライアント側でこれらの計算を実行することにある程度の重みが生じます。
私の意見では、最も重要な考慮事項はコードの保守性です。データベースを使用する場合、データベース自体にビジネス ルールを組み込む必要があります (たとえば、どのエンティティがどのエンティティに関連付けられているかなど)。コードを維持する上での大きな問題は、ビジネス ロジックがさまざまなシステムに分散していることです。私は、そのようなロジックが可能な限り凝縮され、異なるレイヤー間で非常に明確な API を作成するアプローチを採用することを好みます。
このようなアプローチでは、データベースへの「読み取り」アクセスはビューを介して行われます。あなたが話しているロジックはビューに入り、データベースのすべてのユーザーが利用できるようになります-データベースを使用するさまざまな機能間で一貫性を確保します。「書き込み」アクセスはストアド プロシージャを介して行われ、ビジネス ルールが一貫してチェックされ、操作が適切に記録されるようにします。
好みの問題かもしれませんが…
... Alma Do Mundoによるものとは正反対の答えを与えるために、節で行われる (そうではない) 単純な計算のためにSELECT ...
、私は通常、DB を「電卓として」使用することを推し進めます。
(節内の) 計算はSELECT ...
、クエリの実行中に最後のステップとして実行されます。この時点では、関連するデータのみが使用されます。すべての「大きな仕事」はすでに完了しています (処理JOIN
、where 節、集約、ソート)。
この時点で、データに対していくつかの算術演算を実行することによる余分な負荷は非常にわずかです。これにより、アプリケーションと DB サーバー間のネットワーク トラフィックが削減されます。
それはおそらく好みの問題だと思います...