SQLクエリ
この記事は作成中です。この新しいバージョンはどの程度参考になりましたか。投票でお聞かせください。
SQL要素を使用すると、アプリケーションのカスタムSQLクエリを実行、テストおよびレビューすることができます。要素は柔軟なデータ操作を提供しますが、該当する場合はAggregateを使用することをお勧めします。Aggregateは、高度に最適化され保守も容易です。
SQLクエリは、入力パラメータのみを介して送信されるデータにアクセスできます。その他のロジックは、SQLが返したデータにのみ出力を介してアクセスできます。
- 入力パラメータ
- 入力パラメータを提供することにより、SQLクエリに動的データを使用できます。入力パラメータは必須ではありません。SQL文で入力パラメータを参照するには、
@CustomInputParameter
のように、@
のプレフィックスを使用します。 - 出力パラメータ
-
OutSystemsのSQLクエリには、実行されたクエリが結果を返さない場合でも常に2つの出力パラメータがあります。
-
List:クエリが返した結果のリスト。結果が何もない場合、リストは空です。
-
Count: クエリが返したレコードの数(SQL Max Recordsプロパティは考慮されません)。
-
- 出力ストラクチャ
-
出力ストラクチャは必須です。クエリが返す構造(列のデータ型)を定義する必要があります。エンティティやストラクチャの組み合わせを使用できますが、アトリビュートの順序/データ型がSelectと一致している必要があります。出力ストラクチャは、SQL文が結果を返さない場合でも必要です。
-
例1: Employeeエンティティのすべてのアトリビュート(
Id
、Name
、Email
、PhoneNumber
の各アトリビュート)を選択する場合、Employeeエンティティを出力ストラクチャとして指定します。 これにより、SQLクエリのList出力パラメータがEmployee Listデータ型を返すようになります。 -
例2: 同じEmployeeエンティティの
Name
とEmail
のみを選択する場合、必要なアトリビュートを保持するストラクチャ(EmployeeInfo)を作成して出力ストラクチャとして使用します。 SELECT文のアトリビュートのデータ型および順序がEmployeeInfoストラクチャのアトリビュートのデータ型および順序と一致している必要があります。これにより、SQLクエリのList出力パラメータがEmployeeInfo Listデータ型を返すようになります。
-
SQLクエリでエンティティを参照するには、波括弧の間に記述します(例: {User}
)。SQLクエリでエンティティアトリビュートを参照するには、角括弧の間に記述します(例: [PhoneNumber]
)。
独自のSQLクエリを作成する
以下の手順を実行します。
- SQL要素をアクションフローに追加します。
- 必要に応じて、クエリパラメータを定義します。
- SQLクエリを作成します。
- SQLノードの出力に使用される出力ストラクチャを定義します。
- SQLノードの出力リストを使用して、SQLクエリの結果にアクセスします。
SQLクエリをテストする
SQLエディタの下部にある[TEST
]ボタンをクリックして、動作をテストすることができます。テストを成功させるには、以下を確認します。
-
クエリパラメータ
がある場合は、先に[Test Inputs]タブでテスト値を割り当てておく必要があります。注記: 値が割り当てられていない場合、空の値でクエリがテストされます。
-
SELECT
文のアトリビュートと一致する出力エンティティ/ストラクチャが1つ以上あります。 -
[TEST]をクリックします。
注記およびガイドライン
SQL要素を使用する場合には以下の点を考慮します。
- データ定義言語を避ける
- SQLツールの使用は、次の操作を実行する場合に限定する必要があります。
SELECT
、INSERT
、UPDATE
およびDELETE
文。CREATE TABLE
、ALTER TABLE
、DROP TABLE
等のDDL(データ定義言語)を使用すると、OutSystemsメタモデルの一貫性が損なわれ、誤動作を招く可能性があります。 - 物理層のクエリを使わない
- OutSystemsメタモデルの一貫性を常に保証するため、メタモデルの物理テーブルに直接クエリを実行することはできません。プレフィックス
OSLOG
、OSSYS
またはOSUSR
を持つテーブルをクエリで使用すると、プラットフォームはエラーメッセージを表示します。 - 例外によってトリガーされるロールバック
- OutSystemsは、Webリクエストがサーバーに届いたらトランザクションを開始し、ユーザーに応答を返す前にトランザクションをコミットします。例外が捕捉されずに残った場合、データの一貫性を常に保証するため、トランザクションはロールバックされます。これは、クエリがトランザクションの内部で処理され、失敗した場合は変更がロールバックされることを意味します。
- ランタイムユーザーの権限の確認
- クエリは、Configurationツールで指定されたランタイムユーザーを使用して、データベースでテスト・実行されます。このユーザーが、クエリで指定されたSQL文を実行する権限を持っていることを確認する必要があります。権限がない場合、実行時にそのクエリを実行したり、テストしたりするとエラーが発生します。
- データベースサポートの確認
- Database ModuleプロパティがAllに設定されていると、OutSystemsは、サポートされているすべてのデータベースにクエリが適合していることを確認します。適合していない場合は、警告メッセージが表示されます。
- クエリパラメータのExpand Inlineプロパティを有効にしない
- パラメータをインラインに展開して適切に使用することは困難です。なぜならば、すべてのユーザー入力を適切にエスケープ処理してからSQL文で使用する必要があるからです。できる限り、このプロパティを完全に有効にしないでください。
OutSystemsには、このプロパティを有効にせずに一般的なユースケースを実装する方法があります。「動的SQL文の適切な作成」をご覧ください。
AggregateをSQLに変換する
アプリケーションが大規模になるにつれ、既存のAggregateを変更して別の方法でデータを取得する必要がある場合があります。ユースケースで、サブクエリやIN句などのより高度なデータの取得を行う必要がある場合、AggregateではなくSQL要素を使用する必要があります。このような場合は、既存のAggregateをSQL要素に変換し、元のAggregateから生成されたSQLの改良を続けることができます。
SQL要素ではクエリを改良することができるのに対し、Aggregateには以下のようなメリットがあります。
-
Aggregateの実行時SQL文は必要な数の行および列を取得できるように最適化されています。
-
Aggregateのほうが管理が簡単です。
このため、最初は必ずAggregateを使用してデータを取得し、必要な場合にのみSQL要素に変換するようにしてください。
制限事項
AggregateをSQL要素に変換できるのは、Aggregateに以下が含まれない場合のみです。
- ソース内のストラクチャ
- 計算アトリビュート
- アトリビュートごとのグループ
- 動的ソート
リアクティブWebおよびモバイルアプリの場合、クライアントアクションや画面のAggregateでは、この機能を使用できません。
AggregateをSQL要素に変換する方法
既存のAggregateをSQL要素に変換するには、以下の手順を実行します。
-
アクションフローで、変換するAggregateをダブルクリックします。
-
[Aggregate]ウィンドウで、
Executed SQL
プロパティをダブルクリックして[Executed SQL]ウィンドウを開きます。 -
[CONVERT AGGREGATE TO SQL]をクリックします。
[CONVERT AGGREGATE TO SQL]ボタンは、Aggregateに上記の制限事項が含まれていない場合にのみ有効になります。
-
[PROCEED]をクリックします。
これにより、アクションフローに元のAggregateをベースにしたSQL要素が追加されます。 アクションフロー内の元のAggregateは保持されますが、無効になります。新しいSQL要素のクエリ結果を検証した後、この無効になったAggregateは削除することができます。