👦🏽 👨‍👩‍👦‍👦 🥣 保存された手順の害 👩🏻‍🌾 ✋🏿 🕺🏼

ポッドキャスト「ZincProd」のチャットで、彼らは、一部の人がすべてのビジネスロジックをpl / pgsqlのストアドプロシージャに転送する方法についての記事を落としました。そして、この記事には多くの利点があったので、そのようなリファクタリングを積極的に認識した人々、そしておそらく彼らの大多数さえいることを意味します。

私は自分の考えをツリーに沿って広めることはしませんが、保存されたプロシージャを使用することの多くの不利な点をすぐに投げ込みます。

保存されたプロシージャの短所

バージョン管理

phpコードの場合、gitで別のブランチに切り替えて何が起こったかを確認できる場合でも、ストアドプロシージャをデータベースにプッシュする必要があります。また、従来の移行はここでは役に立ちません。ストレージへのすべての変更を新しいCREATE OR REPLACE PROCEDUREとして書き込むと、コードレビューに地獄が発生します。常に新しいファイルがあり、比較するのは理解できません。したがって、いくつかの追加のツールを探すか、バイクを作成する必要があります。

pl / pgsql言語自体

これは、まったく進化していない90年代の時代遅れの手続き型言語です。OOPやFPなどはありません。構文上の砂糖のわずかなヒントのない構文。

たとえば、変数は、プロシージャの先頭で、特別なDECLAREブロックで宣言する必要があります。これは私たちの祖父がしたことです。これにはPascal言語に一定の懐かしさがありますが、2020年ではありません

。phpとpl / pgsqlで同じことを行う2つの関数を比較してください。

CREATE OR REPLACE FUNCTION sum(x int, y int)
    RETURNS int
    LANGUAGE plpgsql
AS $$
DECLARE
    result int;
BEGIN
    result := x + y;
    return result;
END;
$$;

function sum(int $x, int $y): int
{
    $result = $x + $y;
    return $result;
}

約2〜3倍の落書き。

また、言語は解釈され、JITなどはありません。（最近のバージョンで何か変更があった場合は訂正してください）。それら。すべてが非常に遅くて悲しいです。ある種のストレージを使用する場合は、純粋なSQLまたはv8（つまり、javascript）で。

デバッグ

私を信じてください、phpコードのデバッグは100500倍簡単です。何かを修正して結果を確認しました。エコーをオーバーレイしたり、IDEのxdebugを介してそこにあるものを確認したりできます。

保存されたプロシージャのデバッグは不便です。これは、pgadminで（特別な拡張機能を有効にして）実行する必要があります。PgAdminは、利便性の点でPHPstormからはほど遠いです。

ロギングとエラー処理

stdoutから落ちてくる痕跡のある美しいjsonを忘れて、次にグレイログと歩哨に。そして、これがすべて自動的に行われるように、コントローラーが例外をキャッチしない場合、ユーザーに500エラーを与えます。

pl / pgsqlストレージでは、すべてを手動で行います。

GET DIAGNOSTICS stack = PG_CONTEXT;
      

        
        
        
      

    
RAISE NOTICE E'---   ---\n%', stack;

メトリックの収集

golangのように、/メトリックエンドポイントを追加することはできません。これは、Prometheusによって吸い込まれ、監視のためにビジネスやその他のメトリックを詰め込みます。pl / pgsqlを使いこなす方法がわかりません。

スケーリング

ストアドプロシージャの実行は、データベースサーバーのリソース（CPUなど）を浪費します。他の言語の場合、ロジックを他のノードに移動できます。

依存関係

phpでは、composerパッケージマネージャーを使用して、インターネットから目的のライブラリを一度にプルできます。jsの場合と同様に、npmになり、Rustの場合は、貨物などになります。

pl / pgsqlの世界では、苦しむ必要があります。この言語には依存関係マネージャーはありません。

フレームワーク

現代の世界では、Webアプリケーションは最初から作成されるのではなく、そのコンポーネントを使用するフレームワークに基づいて組み立てられることがよくあります。たとえば、Laravelには、ルーティング、リクエストの検証、テンプレートエンジン、認証/承認、あらゆる場面で100,500のヘルパーなどが用意されています。時代遅れの言語で、すべてを一から手作業で書くこと-感謝しません。

自転車はたくさんありますが、後でメンテナンスする必要があります。

ユニットテスト

pl / pgsqlストアでユニットテストを整理することがどれほど便利か想像するのはさらに困難です。私はそれを試したことがありません。コメントで共有してください。

リファクタリング

データベース（Datagrip）を操作するためのIDEがありますが、リファクタリングツールは一般的な言語に対してはるかに豊富です。あらゆる種類のリンター、コードを簡素化するためのヒントなど。

小さな例：記事の冒頭で示したコードの中で、PHPStormは、変数が$resultオプションであり、それを実行できるというヒントを示しました。plpgsqlreturn $x + $y;

の場合-silence。

保存された手順の長所

バックエンドDBパスに沿って中間データを転送するためのオーバーヘッドはありません。
クエリプランはストアドプロシージャにキャッシュされるため、数ミリ秒節約できます。それら。クエリのラッパーとして、熱狂的な高負荷があり、クエリ自体が迅速に実行される場合は、それを実行することが理にかなっている場合があります（まれに、pl / pgsqlではなく、ベアsqlで）。
postgresの拡張機能を作成する場合、ストレージなしでは実行できません。
セキュリティ上の理由で一部のデータを非表示にする場合は、アプリケーションに1つまたは2つのストレージへのアクセスのみを許可します（まれなケース）。

結論

私の意見では、保存されたプロシージャは、それなしでは実行できないと確信している非常にまれなケースでのみ必要です。その他の場合、開発者の生活を複雑にするだけで、大幅に複雑になります。

元の記事でロジックの一部がSQLに転送された場合、これは理解できます。しかし、なぜストレージが謎なのか。

私が間違っていると思われる場合、または保存されたプロシージャ（長所と短所の両方）に関連する他の状況を知っている場合は、コメントにそれについて書いていただければ幸いです。

保存された手順の害