私はプロのソフトウェア開発者にとって非常に新しいと言って、この質問の前置きをします。
私は社内の他のグループからデータを受け取り、このデータをビジネスエグゼクティブが使用できるレポートに変換するチームで作業しています。
データの転送と解析の過程で、データの多くの処理を行ういくつかのSQLステートメントがあります。ほぼすべてのSELECT用途はTRIM、SUBSTR、CASTなど広範囲に適切なサイズや形式にフィールドを軽減します。さらに、CASE内SELECTのステートメントを使用することで説明される特別なケースがたくさんあります。
私たちが使用するTeradataサーバーソフトウェアは、非常にわかりにくいエラーメッセージを出力します。その結果、どのデータがどのSQLステートメントを壊しているかについて、多くの推測を行います。
私の質問は、これらのやや複雑なSQLステートメントを、処理と特殊なケースの処理を省略した、より複雑でない形式に減らし、代わりにこれを外部のスクリプトまたはプログラムで実行することは良い考えでしょうか？これは意味がありますか？
回答:
SQLから処理コードを移動することの大きな利点は、SQLの管理がはるかに簡単になることです。
欠点は、これらのクエリを他のプログラムで使用したい場合は、結果処理プロセスを他のプログラムで使用できるようにする必要があることです。必要なクラスを含むライブラリファイルをコピーするのと同じくらい簡単ですが、それでも、ライブラリへの変更はすべて反映され、すべてのクライアントが新しいライブラリで再構築される必要があることを意味します。
別のオプション：ほとんどのフォーマットコードを含めるために、ビュー（または、クライアントごとに異なるフォーマットの結果が必要な場合は複数のビュー）を使用しないのはなぜですか？これにより、必要に応じて、「生の」クエリ結果、または適切にフォーマットされたクエリ結果を取得できます。
このロジックにビューを使用することについてすでに提案されていることに同意します。Caseステートメントについてもう1つ追加したいと思います。SQLからCaseステートメントをプルすると、システムのパフォーマンスに大きな影響が出る可能性があることに注意してください。これらのCaseステートメントは、返されるデータの量を大幅に削減している可能性があります。SQLステートメントを使用してデータベースレイヤーでCaseフィルタリングを実行すると、通常、すべてのデータを元に戻し、外部スクリプトまたはプログラムでフィルタリングを実行するよりもはるかに効率的です。これを検討している場合は、そのソリューションに進む前に、データ分析とパフォーマンステストを行うことを強くお勧めします。
外部プロセスを追加すると、通常、システムのデバッグが難しくなりますが、状況によって異なります。 あなたの判断を使用してください。帯域外プロジェクトの開発/維持に必要な時間を考慮してください。
すでにETLプロセスを使用していますか？Teradataの経験はありませんが、ステップを分離することで、何が起こっているかをより明確に把握できます。2秒の概要は次のとおりです。
これは通常、このタイプのシステムを正常に管理するのに十分な情報を提供します。
これらはsomone / thingが消費するデータを生成する実際のロジックに関連しているため、CASEビットはそのままにしておく傾向があります。したがって、これらを取り出すことは、より大きなデータセットを送り返す必要があり、クライアントはそれに対して何らかの処理を行う必要があることを意味します。これで、レポートの「ロジック」が2つの別々のレイヤーに分割されましたが、これは良くありません。
しかし、私はあなたのコードからフォーマットをホットブリックのようにドロップします（それが具体的にJOIN述語の一部である場合を除いてなど）。それはフォーマットが消費者の仕事だからです...なので、Excel、Crystalなど、どのようなレポートツールでも使用します。正しいロケールとすべてのジャズでのものをフォーマットするのが得意です。クライアントが得意なことを実行できるようにし（物事をきれいな色で表示する）、サーバーが最も得意とすること、つまりデータの処理にサーバーが集中できるようにします。