クライアントがローカルデータベースに対してクエリ（または「ルール」）を作成し、特定のアクション（メール、テキストメッセージなどの送信）をトリガーできるようにする小さなアプリを提供する必要があります。
彼らは仕事の実際のSQLを述べることができるので、私のデータレイヤーはどのように見えるのだろうかと思います。すべてのデータの相互作用は弱く型付けされるため、エンティティとリポジトリは必要ないようです。
では、データレイヤーは何をすべきでしょうか？接続を開き、入力SQLを受け入れて、プロパティバッグのリストを返しますか？このためのデータレイヤーも必要ですか？
[アップデート]
これは、クライアントがデータベースに対してクエリを記述または構築できるようにするために、自分のアプリに必要なものです。ローカルコンピューターで実行されるため、悪意のある従業員にとってSQLインジェクション攻撃は不要です。
しかし、クエリの作成、検証、サニタイズを視覚的に制御できる場合でも、このレイヤーの最終結果はSQLコードになりますね。テストしたい場合、どうすればそれを抽象化できますか？
一般に、このようなコードは攻撃を受けやすいため、ユーザーから直接クエリSQLへの入力を受け入れることは危険であると考えられています。代わりに、これが1回限りのケースではなく、ユーザーが何かをクエリできる柔軟性を提供したい場合は、ユーザーがフィルタリング基準を指定するために使用する中間言語を定義する必要があります。 SQLクエリの生成。このように、あなたは持っていますSQLSQL Injection
これは、プロジェクトの1つで行い、基になるデータモデルの属性をフィルタリング、並べ替え、グループ化する柔軟性をユーザーに提供しました。このアプローチは非常にうまく機能します。
PL / SQL以上のETLツールを使用してレポートデータベース/スタースキーマを構築します。これにより、データのクリーンアップ/強化、ビジネスルールの事前適用、専門用語ではなく列とテーブルのビジネス言語の使用、ユーザークエリの戻り値の取得が可能になります高速で、Cognosのようなレポートツールをスタースキーマに配置します。スタースキーマは、ユーザーのすべてのテーブルを事前に結合し、ユーザーからの愚かさを防ぐためにガバナーシップルールを適用できるようにします。
これが最も簡単で効果的な方法ですが、安くはありません。
実際、10年以上前にほぼ同じ問題が発生しました（ローカルデータベースにはありませんでしたが）。アドホックSQLクエリのIMHO（作成されたとしても、ユーザーはテキストシェルを使用して入力することができます）、DALはあまり意味がありません-アプリケーションの一般的なレポート/クエリ部分の場合。これは、データが変更されたりデータベースに入力されたりするアプリケーションの部分にDALを設定できないことを意味するものではありません。
ただし、いくつかの点に注意する必要があります。明らかに、構文的に正しくないクエリは意味のあるエラーメッセージを表示するはずであり、長時間実行されるクエリを中断する可能性があるはずです。
データモデルの技術的な部分をユーザーから隠すために、特定のテーブルへのアドホッククエリアクセスを制限するか、特定のビューのレイヤーを提供することもお勧めします。また、ユーザーが同様のアドホックな方法でデータを変更できるようにすることは避けます。ユーザーが作成したSELECTステートメントにUPDATEステートメントを挿入できないようにしてください。