Q&A
>UIの話でしょうか？
いえ、データ検索方法についてです。
>逆にクライアントが直接SQL文自体を書くことはスキルというより
>インジェクションの問題でありえないでしょう
クライアントとかそういうことではなくて、サーバー側で、動的に検索するカラムを変更して検索する方法について質問させていただいてます。
お世話になります。
タイトルだけだと説明がわかりづらい可能性があるので、
例を提示させていただきます。
name = "hoge" AND age >= 30 AND jyusho LIKE "%埼玉%" AND ...
といったようなGrepを連鎖させる様な実装って、
検索するカラムが多ければ多いほど、RDBだとやりづらいと思うのですが、
一般的には、SQLクエリを動的に作る実装にするのでしょうか？
それとも、ElasticSearch等の全文検索エンジンで、実装するものでしょうか。
（もっとわかりやすい例を提示させていただくと、
下記のiTunesのスマートプレイリスト作成のような検索機能の実装方法についての質問です）
回答3件
0
ベストアンサー
作ろうとしているシステムが、
柔軟な検索を主目的としたものなら、
検索の柔軟性とレスポンスを第１に考えて手法を選択すべきかと思います。
その場合は全文検索エンジンになるのかな？
そうではなくて、システムの主目的が他にあるんだけど、
一部（例えばマスタ検索など）、
柔軟な検索が必要な部分があると言う程度であるなら、
私なら、検索の柔軟性は我慢して貰ってでも、
レスポンスと検索結果の再利用性を優先させて手法を選択します。
その場合、多くはSQLになるのかな？
RDBと全文検索システムの２本立てと言う方法も考えられますが、
マスタ反映のタイムラグと反映にかかるコストが問題になることがあります。
実務経験では全文検索ではなくOLAPですが、
RDB側で締め処理をして、OLAPにデータを送って、
更新が完了してキューブが完成するまで数時間。
結果は午後にならないと見れませんなんてシステムもあったりしました。
そうした用途とか問題点とかを天秤にかけながら、
手法を選択するのが良いと思います。
投稿2017/06/06 04:57
総合スコア324
0
"SQLを生成するツールを作って実装している" に一票入れます。
投稿2017/06/06 04:14
総合スコア4150
0
UIの話でしょうか？
UIはいわゆるフールプルーフ的な誰が見てもどうやっても
問題ないような作りをするため専用の入力画面をつくります
入力画面自体はWEBベースでもいいし、アプリベースでもいいでしょう
逆にクライアントが直接SQL文自体を書くことはスキルというより
インジェクションの問題でありえないでしょう
投稿2017/06/06 04:14
総合スコア114769
ということは、WHERE句の書き方についてですね？
これは粛々と条件を羅列していくだけなのでなにも悩むものはないのでは？
ちなみに
> サーバー側で、動的に検索するカラムを変更して検索
っていうのはUIの話にしか思えないですが・・・
＞これは粛々と条件を羅列していくだけなのでなにも悩むものはないのでは？
つまり、「SQLを生成するツールを作って実装」ということですか？
そのWHERE句を、AND条件の数も、評価式も動的に変更でき、検索できるようにするにはどうすればよいのかって話です。
ツールというよりプログラムで書くのが基本だとおもいます
＞ツールというよりプログラムで書くのが基本だとおもいます
それはそうです。プログラムからSQL文を生成するという意味でのツールです。つまりメソッドです
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/06/06 05:38 編集
2017/06/06 06:48