2017-08-31 4 views
0

ユーザーは未加工の未変更の入力データを標準化された最終テーブルにマップできます。動的SQLを使用しないカスタムSQL列の式

一般に、特別なロジックを必要とせずに単純な1対1の一致です。

たとえば、 raw_table.raw_col_1、final_table.col_1にマッピングされますraw_table.raw_col_2はfinal_table.col_2にマップされます、など

しかし、一人の顧客は、次のようにfinal_table.col_3をマッピングする必要が能力を望んでいる:

case 
    when (raw_col_1 = 'S12' and raw_col_2 = 'D18') or raw_col_3 is not null then raw_col_3  
    else 'GF17' 
end 

他にも同様の要求があります。

final_tableをロードするときに、動的SQLを使用して簡単にこれを実現できます。しかし、これは私たちにSQLインジェクション攻撃を開放します。

動的SQLを使用せずにこのタイプのカスタムフィールドマッピングを許可できる方法はありますか?

+0

これを可能にする変数をクエリに追加します。 'case when(@var = trueおよびraw_col_1 ...)... else raw_col_3 end' –

+0

私は単純な答えがいいと思います。それは一定ではありません(*他の同様の要求も同様に存在します。*)ので、ユーザー主導型の変動性に対応するためには動的でなければなりません。 –

答えて

1

開発ツールが実行時にエンドユーザーに公開されるようになってきています。ある時点では、コードの能力を必要とするか、模倣するほど複雑になります。いくつかのオプションがあります。

1)ユースケースを考慮に入れることができるユーザーインターフェイスを提供します。たとえば、簡易クエリビルダです。個々のコンポーネントのすべてが有効かどうかを確認してください。これが実現可能かどうか、複雑さのレベルを終了し、そのようなユーザーインターフェイスにどれくらいの労力をかけたいかを決定します。

2)より高度なロジックを提供するためのカスタマイズ可能な管理レベルを提供します。これはOracleデータベースなので、値を返すことのできるPL/SQL関数として提供することができます。

2番目のオプションは、ユーザーインターフェイスまたはバックエンドローダー経由で実行できます。ただし、いずれの場合でも、管理者はこれが特権の高い機能であることを理解し、何が入って来るのか、誰にアクセスするのかを監査する必要があります。

パッケージを限定されたスキーマに限定するように設定することもできます(ただし、定義者の権限で呼び出されます)。ただし、これを実行する最善の方法は、使っている。 12cは、この領域でより多くのセキュリティ機能を提供します。

関連する問題