私は最近 PostgreSQL を少し使っていますが、私が素晴らしいと思うことの 1 つは、スクリプト関数などに SQL 以外の言語を使用できることです。しかし、これが実際に役立つのはいつでしょうか。
たとえば、ドキュメンテーションによると、PL/Perl の主な用途は、テキスト操作が非常に優れていることです。しかし、それはアプリケーションにプログラムする必要があるものではありませんか?
次に、信頼できない言語を使用する正当な理由はありますか? すべてのユーザーが任意の操作を実行できるようにすることは、運用システムでは悪い考えのようです。
PS。誰かがPL/LOLCODEを有用に思わせることができればボーナス ポイント。
@マイク：この種の考え方は私を緊張させます。「これは無限に移植できるはずだ」と何度も聞いたことがありますが、質問されたとき、実際に移植があると予想していますか? 答えはノーだ。
最小公分母に固執すると、抽象化レイヤー (ORM、PHP PDO など) の導入と同様に、パフォーマンスが大幅に低下する可能性があります。私の意見は次のとおりです。
ところで、リレーショナル データベースと非リレーショナル データベースを混在させています (たとえば、CouchDB は Oracle に匹敵する RDBMSではありません)。
「その[テキスト操作]は、アプリケーションにプログラムする必要があるものではありませんか？」
通常、はい。一般的に受け入れられているデータベースの「3層」アプリケーション設計では、ロジックはクライアントとデータベースの間の中間層にある必要があります。ただし、トリガーにロジックが必要な場合や、関数のインデックスを作成する必要がある場合があり、データベースにコードを配置する必要があります。その場合、通常の「どの言語を使用すればよいですか？」質問が出てきます。
必要なロジックが少ししかない場合は、おそらく最も移植性の高い言語（pl / pgSQL）を使用する必要があります。ただし、本格的なプログラミングを行う必要がある場合は、より表現力豊かな言語（pl / rubyなど）を使用したほうがよい場合があります。これは常に判断の呼びかけになります。
「信頼できない言語を使用する正当な理由はありますか？」
上記のように、はい。繰り返しになりますが、可能な場合はファイルへの直接アクセス（たとえば）を中間層に配置するのが最善ですが、トリガーに基づいて処理を開始する必要がある場合（中間層で直接利用できないデータへのアクセスが必要になる場合があります）、信頼できないものが必要になります言語。これは理想的ではなく、通常は避ける必要があります。そして、あなたは間違いなくそれへのアクセスを守る必要があります。
最近、DBMSの「ユニーク」または「クール」な機能は、私を非常に緊張させます。発疹が出て、かゆみが治まるまで仕事をやめなければなりません。
不必要にプラットフォームに閉じ込められるのは嫌いだ。データベース内のPL/Perlでシステムの大きなチャンクを構築するとします。または、SQL Server内のC＃、またはOracle内のPL / SQLには、多くの例があります*。
ここで、選択したプラットフォームが拡張できないことに突然気付きます。または十分に速くありません。か何か。さらに悪いことに、データベースブロック（MonetDB、CouchDB、Cacheなど）にすべての問題を解決する新しい子供がいます（私のような唯一の問題がクールでないデータベースプラットフォームを持っている場合でも）。そして、アプリケーションの半分を再コーディングせずにそれに切り替えることはできません。
（*確かに、有料の製品は、独自の機能を使用するように説得することで、ある程度あなたを閉じ込めようとしています。これは、無料のプロバイダーで直接平準化できる非難ではありませんが、効果は同じです）。
だから、それは質問の最初の部分の暴言です。しかし、心から感じました。
信頼できない言語を使用する正当な理由はありますか？すべてのユーザーが任意の操作を実行できるようにするのは悪い考えのようです
私の良さ、そうです！一種の「Perlインジェクション攻撃」？何が起こるかを見るためだけにそれをする価値はほとんどあると私は思っていたでしょう。
上で概説した哲学的な理由から、私はPL/LOLCODEチャレンジを引き継ぐと思います。それが現存する何かへのリンクであることを発見したことに私は幾分驚いたが。
手続き型言語の信頼できないバージョンでは、システム上の I/O にアクセスできます。これは、トリガーが必要な場合や、電子メールを送信したり、ソケット サーバーに接続してポップアップ通知を送信したりする必要がある場合に便利です。このタイプのものには多くの用途があり、postgresql の分離レベルにより、このようなことを安全に行うことができます。関数にチェックポイントを配置して、トランザクションが失敗した場合に電子メールなどが出ないようにすることができます。これを行うことの良い点は、クライアントからロジックを削除してサーバーに置くことです。
私の観点からは、答えは「場合による」と思います。
データの操作はデータベース層に属しているため、ビジネス ロジックは操作がどのように発生するかについて過度に心配する必要がなく、操作が行われたことを認識しているだけであるという議論があります。
db レイヤーでデータを処理するもう 1 つの非常に適切な理由は、クランチされるデータの量がネットワーク帯域幅の問題になることを意味する場合です。非常に大量のデータを分類しなければならなかったことがあります。アプリケーション層でこれを処理することは、処理のためにネットワークを介してすべてのデータを転送するのに必要な時間によって厳しく制限されていました。
次に、PL/pgSQL でビニング アルゴリズムを作成したところ、はるかに高速に動作しました。
信頼できない言語に関しては、Josh Berkus (postgres 支持者) からのポッドキャストを聞きました。彼は、処理の一部として MySQL からデータを取り込む postgresql のアプリケーションについて話し合っていたので、通信自体は postgres サーバーによって処理されました。完全な詳細は覚えていませんが、 FLOSS Weekly ポッドキャストにあったと思います。これは、PostGRESQL の歴史とそれに関連するいくつかの問題について非常に興味深い議論です。
私が最近外部言語で書いた、pl/sql では不可能な便利なストアド プロシージャの例は、SQL テーブル ジェネレータが実行時に利用可能な空き領域が最も多いテーブルスペースを選択できるようにする 'df' のバージョンです。
私は plperlu を使用しましたが、比較的単純でしたが、データの型付けには注意が必要でした。
ほとんどの追加言語が提供されているため、その言語で定期的に開発する場合は、db 関数やトリガーなどを快適に記述できます。これらの機能の有用性は、データにできるだけ近いデータの制御を提供することです。可能。