AppMaster は、データベースを操作するための広範な機能を提供します。たとえば、検索ブロックを使用すると、必要なデータを検索し、関連するテーブルをそれに添付し、正しい順序で並べ替えることなどができます。ただし、特定の状況では、これでは不十分な場合があり、その場合は SQL Exec ブロックが使用されます。救助。これにより、SQL の能力を最大限に活用してデータベース クエリを実行できます。
書籍のカタログが含まれるデータベースの例を使用して、ブロックの操作を考えてみましょう。
少し準備作業をしてみましょう。最も単純な形式で、リクエストの送信とその結果の受信を可能にするビジネス プロセスを作成する必要があります。
このビジネス プロセスにアクセスできるようにするエンドポイントも作成する必要があります。
初期段階ではこれで十分です。アプリケーションを公開してテストに進むことができます。このためには、公開時に自動的に作成される Swagger を使用すると非常に便利です。
データベースからすべての書籍をリクエストする単純なクエリを使用します。
SELECT * FROM public.book
テーブル自体 (データベース エディタで作成された他のすべてのテーブルと同様) には、スキーマを示すプレフィックス (public) が付いていることに注意してください。
リクエストが正常に完了し、結果が受信されたことを確認できます。
しかし問題は、この形で答えを認識するのが非常に難しいことです。考えられる解決策は、リクエストを少し変更して、本のタイトルやページ数など、必要なフィールドのみを残すことです。さらに、制限を設定し、データベースからすべての書籍をリクエストするのではなく、10 冊までに制限することも合理的です。
public.book LIMIT 10 から名前、ページを選択します
かなり良くなりましたが、まだ実際の使用には適していません。結局のところ、ビジネス プロセスでは、リクエストを受け取るだけでなく、その結果に対して何かを行う必要があります。このためには、結果をテキスト形式で取得するだけでは十分ではありません。さらなる使用に適したモデルに変換する必要があります。
これを行うには、ビジネス プロセスに戻って少し改良してみましょう。最後のブロックでは、新しい変数、つまり書籍モデルの配列を追加します。
リクエストの結果として受信した JSON をモデルに変換するブロックも必要です。 JSON をモデルに逆シリアル化します。
前のリクエストを繰り返して、視覚的認識と BP でのさらなる使用の両方において、結果がより適切になったことを確認しましょう。
ここで、より複雑なロジックに進むことができます。次のようなビジネス プロセスを作成してみましょう。
- 本のタイトルを入力として受け取ります。
- どのカテゴリ（ジャンル）に属するかを決定します。
- 結果として、同じカテゴリから 3 冊の書籍をランダムに返します (この場合、リクエストの書籍はその中に含まれるべきではありません)。
これを行うために、標準ブロックを使用した検索と SQL クエリの使用を組み合わせた新しいビジネス プロセスを作成します。
最初のブロックは、タイトルで本を検索し、それがどのカテゴリに属しているかを判断することです。これを行うには、次のパラメータを指定して検索ブロックを使用します。
- _With = カテゴリ - 書籍自体に加えて、クエリ結果には関連するカテゴリ テーブルからの情報が必要です。
- _Limit = 1 - 1 冊の本だけを見つける必要があります。
- _Ilike = False - 名前は要求されたものと正確に一致する必要があります。
- 名前 - 本のタイトルのインデックス。Start ブロックから渡されます。
インデックス 0 の Array Element ブロックを使用して、結果から最初 (そして唯一) のブックを取得します。
本は同時に複数の異なるカテゴリに属することができ、この場合、それらのどれも私たちに適しています。 Random 要素ブロックを使用してランダムに選択できます。
この後、必要なデータがすべて揃ったので、あとは次のようなリクエスト自体を作成するだけです。
SELECT * FROM public.book WHERE id IN (SELECT rel1_id FROM public.book_categorys_category_books_pivot WHERE book_categorys_category_books_pivot.rel2_id = X) AND id <> Y ORDER BY random() LIMIT 3
ここで、X は書籍カテゴリの ID、Y は書籍自体の ID です。
このクエリにはサブクエリが含まれていることに注意してください。まず、book_categorys_category_books_pivot テーブル (2 つのテーブル間の関係に関する情報を格納するために使用されます) から、選択したカテゴリに対応するすべての書籍識別子が検索されます。この後、最初にタイトルがビジネス プロセスに渡された書籍 ID を除き、指定された範囲に一致するランダムな 3 冊の書籍を検索するクエリが実行されます。
プロジェクトのデータベース構造をより詳細に調べるには、[展開計画] 設定の [DB を開く] ボタンを使用できます。
これにより、エディターでデータベースを開いて、データの表示と編集に直接アクセスできるようになります。ただし、エディターでデータ構造自体を変更すると、プロジェクトをさらに公開できなくなるという事実を考慮する必要があるため、注意が必要です。
ビジネスプロセスの作成に戻りましょう。リクエストのコンパイルを完了する必要があります。これを行うには、書籍とカテゴリ ID を整数から文字列に変換し、Concat Strings (Multiple) ブロックを使用して最終リクエストを組み立てる必要があります。
最後のステップでは、クエリを実行し、結果をモデルに変換し、それをクエリ結果として End ブロックに送信します。
変更を保存し、エンドポイントを作成し、プロジェクトを公開して、リクエストが正しく機能することを確認できます。この場合、複雑な複合クエリを含む 1 つの SQL Exec ブロックを使用して、他の多くのブロックを置き換え、ビジネス プロセスの構造を簡素化しました。
SQL Exec ブロックの使用はデータの取得に限定されず、さまざまなシナリオで使用できます。さらにいくつかのオプションを詳しく見てみましょう。
- id=X の書籍のコメント数をカウントする
SELECT COUNT(id) FROM public.comment WHERE book_id = X - コメントで与えられたすべての評価を考慮して、書籍の平均評価を計算します。
public.comment WHERE book_id = X から SELECT AVG(rate) - 2023 年より前に書かれたすべてのコメントを削除します (たとえば、ログをすばやくクリアするために使用できます)。
DELETE * FROM public.comment WHERE created_at < '2023-01-01'
結論として、セキュリティを向上させるために、スキーマ変更につながる可能性のある危険な操作に対して SQL Exec ブロックにフィルターが追加されたことは注目に値します。
アプリケーションが AppMaster サーバーでホストされている場合、TABLE|COLUMN|INDEX|CONSTRAINT|SEQUENCE|SCHEMA|DATABASE の CREATE/ALTER/DROP/TRUNCATE はフィルターによって無効になります。オンプレミスでホストする場合 - デフォルトでは、あらゆるリクエストを制限なく利用できます。
