大文字小文字区別なし曖昧検索 (文通!?)

http://d.hatena.ne.jp/jflute/20080625/1214331777

http://d.hatena.ne.jp/mokkouyou2001/20080623/1214220084


<1>
について。
検索用カラムは考えすらしなかったので、ちょっと目からうろこです。


<2>
について

A. DBによって仕様が違う


これに関してですが、
UPPER等の関数自体はACCESS以外のメジャーどころはサポートしているはずです。
その上で、


ILIKE検索があるというのはまた違った方法論かなと。
たとえば、ILIKEを利用せずに、LOWERでやる人もいるかもしれませんし、
せっかくデフォルトであるんだから、そっちを使う・・・
という人もいると思います。


そもそも演算子が違いますので、ILikeSearchOption extends LikeSearchOption
って感じなのかな?という気もします。


まぁそれこそ、ignoreCase(Const.ILIKE)見たいなのOptionでもよいのかもしれませんし、
SQL毎の方言を吸収できる仕掛けがあってもよいのかもしれませんね。


どの程度のコストかは計測してみないとわからないのですが、
パフォーマンスに関しては確かにあるでしょうね・・・
正直なところ、これが大きいと思います。
結構な確率で、規約に縛られそうな気もします。(まぁUnionとかもくさいですが・・・)


なので、私的には、そういったリスクを踏まえた上で利用できる

  1. 手段として提供
  2. 拡張可能(ポイントを用意)
  3. 頑張って拡張しろ

のどれかが満たせればよいと思います。
標準としての扱いではなく、手段として・・・
・・・といっても、用意したらしたで、そのような意図はなかなか伝わらないと思いますが・・・・


ただ、一番困るのは、逃げ道がない・・・ってパターンですから(^^;
dbfluteに関していえば、ソースも展開されるし、VelocityMacroも展開されるので、
拡張という方法もとりやすいかと思います。
(まぁまだまだ急成長のプロダクトという点で独自拡張はちょっと避けたいですが)


とまぁ勝手にぐだぐだと偉そうに
書き並べてしまいましたが、
極論としてお聞き流しください・・・


ちなみに私の中での「大規模ではない」とは、


最悪のケースでも
一人で頑張ればある程度は何とか出来そうな規模
となります。(≒ほぼ全体を把握できている場合)


なので、その時々や、プロダクトで考え(というか考え方)が違うかも。
場合によっては、10人月でも大規模と思うときがありそうな気がします。


手に負えない=大規模