ASTERIA で部分一致・複数可変をマッチングするするのが意外と難しいです。
SQLの完全/部分一致と結合KEYの数が既知(=固定)/未知(=可変)の関係は,
下の表のようにまとめることが出来るかもしれません.
SQLのマッチングのパターン
| 完全一致 | 部分一致 | |
|---|---|---|
| 固定 | ①=演算とor | ②LIKE演算とor |
| 可変 | ③IN句 | ④SQL非対応 |
"織田信長"
"織田信忠"
"豊臣秀吉"
"豊臣秀頼"
"徳川家康"
"徳川秀忠"
①完全一致・固定のとき
普通にWHERE句を"="と "or"で取り出せますし.
select
人名
FROM 社員マスタ A
WHERE A.col1 = '織田信長'
or A.col1 = '織田信忠'
--
-- "織田信長"
-- "織田信忠"
orを使っているため,可変に対応していない.
②部分一致・固定のとき
LIKEとor を組み合わせでいける.
SELECT
A.*
FROM 社員マスタ A
WHERE A.col1 LIKE '%忠%'
or A.col1 LIKE '%秀%'
-- 結果
-- "織田信忠"
-- "豊臣秀吉"
-- "豊臣秀頼"
-- "徳川秀忠"
orを使っているため,可変に対応していない.
ポイントはorが既知である.
③完全一致,・可変のとき
ちょっとせこいですが,
IN句の中を無理矢理でも文字列を整形,、
IN句の引数に代入することが出来れば,
query = "('織田信長','織田信忠')"
可変長といえるでしょう.
SELECT
A.*
FROM A
WHERE A.col1 in $query; -- WHERE A.col in ('A','B')
-- 結果
-- "織田信長"
-- "織田信忠"
ポイントは, query = "('織田信長','織田信忠','豊臣秀吉')"
と"いくつでも"増やせすことが出来るところ.
④部分一致・可変のとき
これがSQLではできない.
僕が知らないだけからも知れない(知ってる方がは教えてください)
-- これは文法的に間違っている
SELECT
A.*
FROM A
WHERE A.col1 in (%忠%,%秀%);
-- 結果は②と同じものを取り出したい.
IN句と%を同時に使用することができない.
MYSQLでwhere句を、記述するときに、inと...
Linuxのgrep使えば,それほど難しいものではないよ
# 引数群をひとつのファイルにまとめる
cat arguments
忠
秀
vi sample.sh
cat arguments |
while read $argument ; do
grep $argument 会社マスタ
done
./sample.sh
# 結果
"織田信忠" # 1回目のループ(=$argument="忠")の出力
"徳川秀忠" # 1回目のループ(=$argument="忠")の出力 ★★★
"豊臣秀吉" # 2回目のループ(=$argument="秀")の出力
"豊臣秀頼" # 2回目のループ(=$argument="秀")の出力
"徳川秀忠" # 2回目のループ(=$argument="秀")の出力 ★★★
★★★が被っているため,
SQLのDISTINCTに相当する処理をかます必要はあるものの,
argumentsファイルの中身が何行になっても対応できる点で可変である.
これはSQLでは出来ないの???
上記を, ASTERIAで実現してみる
ストリーム全体の流れ
ポイント
Linuxのソースコードとまったく同じく,
①argumentsファイルの方だけ, Loop処理
②argumentsファイルの中身をフロー変数(=argument)に格納
(このときストリームのままだと動かなかったので, 注意が必要である.)
Regexpコンポーネント
Linuxのgrepに相当するのが,
ASTERIAでは Regexpコンポーネントを使う.
Regexpのヘルプ
上記を覗くと
■備考のURLが死んでいるorz
また,入力が1つしかないパターンしか例が挙がっていない.
Regexpコンポーネントの
入力1:社員マスタのcol1
入力2:フロー変数のargument
を指定.
Regexpコンポーネントの入力が２つ以上あるとき,
正規表現を書く必要がない(むしろ書いたらダメ!!).→
入力2が”存在する場合、正規表現プロパティを置換”になるから。
注意すべき点
特殊文字, たとえば, ),(などが入力2に含まれると,
エラーが発生するので,制御をかますことが本来必要かもしれない.
まとめ
④部分一致・可変に該当する抽出の仕方は, SQLが非対応のように
本来想定していない抽出の仕方だと思われる.
こうでないと取れない状況に遭遇したとき,
データの構造が本来あるべき姿か,
を見直すことをお勧めする.
あくまで,④は隠し芸程度に留めるべきだと私はおもう.