Kimura A
a.kim****@live*****
2014年 7月 9日 (水) 17:28:51 JST
木村です。須藤さん、村上さんご回答ありがとうございます。 > この「等しくない」のように「○○じゃない」というクエリーは重 > い(*)ので避けられないか考える方がよいです。 これが基本なんですね。 NOT条件を単独では指定できない仕様も、この重さを回避するためなんでしょうね。 これまでも、ときどき強引に「全件ヒットの条件＋NOT条件」で検索するような仕組みを作っては、これって本当はいけないんだろうな…とぼんやり考えておりました。（汗 憶えておきます。 > Groongaでは、空レコードを転置索引を使って高速にできないため > （って教えてもらいました）、私は、MySQLのカラムのDEFAULTの > 機能をつかって、空レコードが入らないようにして、高速に検索 > できるようにしています。 なるほど。 今回の場合、「kana値が未入力のレコード」が一時的に存在することを想定しているので、 ◯kana値が空のレコードは存在する（可能性がある） ◯しかし表示の際は除外しなければならない というのが前提になっています。 なので、お二人のお話を総合すると、 ◯t.kana_empty(BOOL/デフォルト値FALSE)カラムを追加して、name_kanas.kana値が未入力のレコードを除外するためのフラグとして使う ◯アプリケーション側で、name_kanas.kana値が空のtレコードを挿入する際はt.kana_empty=TRUEを設定する ◯アプリケーション側で、name_kanas.kana値が更新される際は対応するt.kana_empty値も自動的に追従させる といったやり方がよさそうです。 おかげさまでやっと正解が見えてきた感じがします！ そしてこのやり方を前提にすると、WHERE句で一元的に書き分ける場合と違って、下掲の処理はまったくの別トピックになってくるわけですね…。 書いてみてよかったです。 >> 将来的に、kana値が「あ」で始まるものだけを取得、などといった応用も考えられるので、ここはぜひとも抑えておきたいところです。 > > それなら「name/kana」にせずに、「kana/name」にして > 「--query name_kana:^あ」でいける気がします。 大変、ためになりました。 そのまま採用させていただくことになりそうです。 お二方とも、どうもありがとうございました。勉強になりました。 特に須藤さん、長々とお付き合いくださってありがとうございましたm(_ _)m
