15

読みやすく、テストしやすいように SQL コードをモジュール化する方法はありますか?

私の SQL コードは、多くの場合、ネストされた結合、内部結合などの長く複雑な一連のものになり、作成もデバッグも困難になります。対照的に、Javascript や Java のような手続き型言語では、名前で呼び出す個別の関数として個別の要素をピンチオフします。

はい、それぞれを完全に個別のクエリとして記述したり、データベースに格納したり、ストアド プロシージャとして記述したりできますが、多くの場合、データベースを変更したり混乱させたりしたくありません。特に DBA が望んでいない場合は、クエリを実行するだけで問題ありません。すべてのユーザーに書き込み権限を付与します。

たとえば、概念的には、複雑なクエリは次のような疑似コードで簡単に記述できます。

(getCustomerProfile) 
left join 
(getSummarizedCustomerTransactionHistory) 
using (customerId) 
left join
(getGeographicalSummaries) 
using (region, vendor)
...

理論的な観点からこのトピックについて多くのことが書かれていることは承知していますが (以下のリンクをいくつか参照)、コードを正しく書きやすくし、一度書いたら読みやすくする方法を探しているだけです。おそらく、実行からではなくても、視覚から複雑さを抽象化するための構文糖衣にすぎません。これは、私が見ないようにしようとしているリテラル SQL にコンパイルされます。類推して...

  • スタイラス: CSS ::
  • CoffeeScript : Javascript ::
  • SAS マクロ言語: SAS 言語 ::
  • ? : SQL

特定の SQL フレーバーが重要な場合、私の作業のほとんどは PostgresQL で行われます。

http://lambda-the-ultimate.org/node/2440

SQL におけるコードの再利用とモジュール性

データベースと関数型プログラミングは対立していますか?

4

2 に答える 2

6

ほとんどのデータベースでは、CTE (Common Table Expressions) を使用して、必要なことを行うことができます。

with CustomerProfile as (
      getCustomerProfile
     ),
     SummarizedCustomerTransactionHistory as (
      getSummarizedCustomerTransactionHistory
     ),
     GeographicalSummaries as (
      getGeographicalSummaries
     )
select <whatever>

これは、単一のクエリに対して機能します。CTE を 1 回定義するだけで、複数回使用できるという利点があります。constまた、定数値を持つCTE という名前をよく定義します。

次のステップは、これらの構造を取り、そこからビューを作成することです。これは、複数のモジュール間でコードを共有する場合に特に役立ち、一定の定義を保証します。一部のデータベースでは、ビューにインデックスを配置してそれらを「インスタンス化」し、処理をさらに最適化できます。

最後に、ストアド プロシージャで挿入/更新/削除をラップすることをお勧めします。これにより、一貫したフレームワークを持つことができます。

さらに2つのコメントがあります。まず、SQL はトランザクション システムやレポート システムによく使用されます。多くの場合、目的に適した形式でデータを取得すると、データ自体が語ります。たとえば、1 週間に 1 回または 1 日に 1 回データが取り込まれる、3 つのサブジェクト領域専用の 3 つのテーブルを持つデータ マートを要求するだけかもしれません。

また、SQL は抽象化のためのアイデア言語ではありません。良い習慣、命名規則、およびインデント スタイルを使用すると、便利にすることができます。マクロ、エラー処理 (データ エラーを特定するのが非常に難しく、処理するのは私には理解できない理由)、共通の機能に対する一貫した方法 (グループ文字列の連結と言えるでしょうか)、およびその他のいくつかのような、「実際の」言語からの特定のことをひどく見逃しています。特徴。とはいえ、データ中心で容易に並列化できるため、他のほとんどの言語よりも便利です。

于 2013-02-04T18:48:29.777 に答える
1

ここでの問題は、データをリレーショナルな方法で考える必要があるということです。この種の抽象化がリレーショナル モデルに正しく適合するとは思えません。SQL をモジュール化するという点では、それがストアド プロシージャや関数の目的です。これらが Java のメソッドと同じ特性を持っていることに注目してください。そのように抽象化できます。もう 1 つの方法は、関心のあるデータをマテリアライズド ビューに抽象化することです。これを行うことにより、これらの実体化されたビューの上に通常のビュー (仮想関数を参照) を配置して、「生の」テーブルに触れることなくデータの構造をテストできます。

于 2013-02-04T18:24:17.050 に答える