postgres の SQL 以外の言語

https://stackoverflow.com/questions/39517

09-06-2019
|

質問

最近 PostgreSQL を少し使っていますが、素晴らしいと思うことの 1 つは、スクリプト関数などに SQL 以外の言語を使用できることです。しかし、これが実際に役立つのはいつでしょうか?

たとえば、ドキュメントには、PL/Perl の主な用途は、テキスト操作に非常に優れていることであると記載されています。しかし、それはむしろアプリケーションにプログラムすべきことではないでしょうか?

第二に、信頼できない言語を使用する正当な理由はあるのでしょうか?すべてのユーザーがあらゆる操作を実行できるようにするのは、運用システムでは悪い考えのようです。

PS.誰かが達成できればボーナスポイント PL/LOLコード役に立ちそうです。

解決

「それ（テキスト操作）はアプリケーションにプログラムすべきものではないでしょうか?」

通常、はい。一般的に受け入れられている「三段" データベースのアプリケーション設計では、ロジックはクライアントとデータベースの間の中間層に配置する必要があります。ただし、場合によっては、トリガーにロジックが必要な場合や、関数にインデックスを付ける必要があり、データベースにコードを配置する必要があります。その場合、通常のすべての「どの言語を使用する必要がありますか？」質問が出ます。

ほんの少しのロジックだけが必要な場合は、おそらく最も移植性の高い言語 (pl/pgSQL) を使用する必要があります。ただし、本格的なプログラミングを行う必要がある場合は、より表現力豊かな言語 (pl/ruby など) を使用した方が良いかもしれません。これは常に判断の余地がある。

「信頼できない言語を使用する正当な理由はありますか?」

上記の通り、はい。繰り返しますが、可能であれば (たとえば) 直接ファイルアクセスを中間層に組み込むことが最善ですが、トリガーに基づいて物事を起動する必要がある場合 (中間層では直接利用できないデータへのアクセスが必要になる場合があります)、信頼できないアクセスが必要になります。言語。これは理想的ではないため、通常は避けるべきです。そして、それへのアクセスを確実に保護する必要があります。

他のヒント

@マイク：このような考えは私を不安にさせます。「これは無限に移植可能であるべきだ」という話を何度も聞いてきましたが、質問されると次のようになります。実際に移植があると予想していますか？答えは次のとおりです。いいえ。

最小公倍数に固執すると、抽象化レイヤー (ORM、PHP PDO など) の導入と同様に、パフォーマンスが大幅に低下する可能性があります。私の意見は次のとおりです。

複数の RDBMS をサポートする必要があるかどうかを現実的に評価してください。たとえば、オープンソースの Web アプリケーションを作成している場合は、少なくとも MySQL と PostgreSQL をサポートする必要がある可能性があります (MSSQL と Oracle はサポートしていない場合)。
評価後、決定したプラットフォームを最大限に活用してください

ところで：リレーショナルデータベースと非リレーショナルデータベースを混在させています (CouchDB はないこれは、認識されている移植性の必要性が何度も大幅に過大評価されているという点をさらに例示しています。

最近、DBMS の「ユニークな」機能や「クールな」機能を見つけると、信じられないほど緊張します。発疹が出てしまい、かゆみが治まるまで仕事を休まなければなりません。

私は不必要にプラットフォームに閉じ込められるのが嫌いです。データベース内の PL/Perl でシステムの大きな部分を構築するとします。SQL Server 内の C#、または Oracle 内の PL/SQL には、たくさんの例があります*。

ここで、選択したプラットフォームが拡張できないことに突然気づきました。または十分な速度がありません。か何か。さらに悪いことに、データベースブロックには新しい子 (MonetDB、CouchDB、Cache のようなものですが、もっとクールなもの) があり、すべての問題を解決してくれるでしょう (たとえ私と同じように、データベースプラットフォームがクールでないということが唯一の問題だったとしても)。また、アプリケーションの半分を再コーディングしない限り、それに切り替えることはできません。

(*確かに、有料製品は、独自の機能を使用するようユーザーを説得することで、ユーザーをある程度囲い込もうとしています。これは、無料プロバイダーを直接非難できる非難ではありませんが、効果は同じです。)

つまり、質問の最初の部分については暴言です。ハートフルだけど。

信頼されていない言語を使用する正当な理由はありますか？ユーザーが任意の操作を実行できるようにしているようです

そうです、そうです！「Perl インジェクション攻撃」の一種でしょうか?何が起こるかを見るだけでも、やってみる価値はほとんどある、と私は思いました。

上で概説した哲学的な理由により、PL/LOLCODE への挑戦は見送ろうと思います。それが現存する何かとのつながりであることを知って多少驚きましたが。

私の観点からすると、答えは「状況による」だと思います。

データの操作はデータベース層に属するため、ビジネスロジックは操作がどのように行われるかを過度に気にする必要はなく、操作が行われたことを認識するだけであるという議論があります。

db 層でデータを処理するもう 1 つの非常に良い理由は、大量のデータが処理されることでネットワーク帯域幅が問題になる場合です。以前、非常に大量のデータを分類する必要があったことがあります。アプリケーション層でのこれの処理は、処理のためにネットワーク経由ですべてのデータを転送するのに必要な時間によって大幅に制限されました。

次に、PL/pgSQL でビニングアルゴリズムを作成したところ、はるかに高速に動作しました。

信頼できない言語に関しては、Josh Berkus (postgres 支持者) のポッドキャストを聞きました。彼は、処理の一部として MySQL からデータを取り込み、通信自体は postgres サーバーによって処理される postgresql のアプリケーションについて説明していました。詳しい内容は覚えていないのですが、載っていたと思います FLOSS ウィークリーポッドキャストこれは、PostGRESQL の歴史と、PostGRESQL が直面するいくつかの問題についての非常に興味深い議論です。

信頼されていないバージョンの手続き型言語を使用すると、システム上の I/O にアクセスできます。これは、電子メールを送信したり、ポップアップ通知を送信するためにソケットサーバーに接続したりするトリガーなどが必要な場合に便利です。この種の用途にはたくさんの用途があり、postgresql 分離レベルのおかげで、このようなことを安全に行うことができます。関数にチェックポイントを設定すると、トランザクションが失敗した場合にメールなどが送信されないようにすることができます。これを行うことの良い点は、ロジックをクライアントから削除してサーバーに配置できることです。

ほとんどの追加言語は、その言語で定期的に開発している場合に安心して db 関数やトリガーなどを作成できるように提供されていると思います。これらの機能の有用性は、データをできるだけデータに近い状態で制御できることです。

私が最近外部言語で作成した、pl/sql では不可能だった便利なストアドプロシージャの例は、SQL テーブルジェネレーターが実行時に利用可能な空き領域が最も多いテーブルスペースを選択できるようにする 'df' のバージョンです。

私は plperlu を使用しました。データの入力には注意が必要でしたが、比較的簡単でした。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow