http://d.hatena.ne.jp/mokkouyou2001/20080623/1214220084 すごい。。。です。修正ポイントを完全に押さえていて脱帽です。 さて、二つ。 ＜１＞ LikeSearchOptionのtoLowerCase()とtoUpperCase()は 本当に単純に条件値の大文字小文字を変換しているだけで、 DB上のカラムに対しては何も処理を施しません。 なので、「大文字小文字区別なし曖昧検索」を実現するためには、 DB上に大文字もしくは小文字統一されたデータが格納されるカラムを 作成する必要があります。 ConditionBeanPlatinumTestが説明足りてなかったので、 取り急ぎ足しておきました。コミット済みです。 ＜２＞ LOWER(HOGE) LIKE LOWER('%PARAM%') ですが、昔頭の中で似たようなこと考えたことあるのですが、 実現に至って無い理由は： A. DBによって仕様が違う LOWER()関数自体は大抵のDBで存在するようですが... PostgreSQLは、ILIKEという大文字小文字区別しない専用演算子があるようです。 SQLServerは、デフォルトだとそもそも大文字小文字を区別しません(COLLATE次第)。 B. インデックスが利用されない 前方一致のときだけの話になりますが、インデックスが利用されなくなります。 OracleでFunctionIndex貼ればOKですが、Oracleだけです。 C. そもそものパフォーマンスが心配 インデックスは利用しないのはOKだとしても、 そもそも比較のたびに左辺のLOWER()が処理されるのは パフォーマンス上どうだろうか！？という心配があります。 (特に何十万件を超えるデータの場合) 「A」はある程度の割り切りでそんなに大きな問題ではありませんが、 「B」と「C」は明確な答えを出さないとつらいかなと感じています。 そんなこともあり、結局、実際の業務では 「DB上に大文字もしくは小文字統一されたデータが格納されるカラム」 つまり、検索条件専用カラムですね、これを作りました。 「夜間バッチ」or「画面からの更新時のトリガ的処理」で表示用の カラムとは別に検索条件専用のカラムを作り、そこに対して、 LikeSearchOptionのtoLowerCase()を使いました。 (もっと昔にも似たようなことやりましたが、 やはり同様のやり方でした。その時は700万件あった...) ということで、ConditionBeanとか外だしSQLとかの話し以前に 左辺に対して関数を極力設定せざるを得ないような状況を作らない 方向が一番良いかと考えています。 とは、言うものの、そんなパフォーマンスを気にするほどじゃない 件数でサクッと「大文字小文字区別なし曖昧検索」がしたい場合も あるかと思います。 なので、ignoreCase()の案はとても興味深いので参考にさせて頂きます！ 本当に深いご利用感謝致します。
