今日は，mysqlでのテーブル設計＆テスト
メインのテーブルは３つ
bib 書誌テーブル
hol 所蔵テーブル
ser シリーズ（書架）テーブル
この3つがあって，それぞれに全文検索するカラムがある。
結局，apache solrを使うにしても，全文検索の性能を出すためには
１つのテーブル，１つのファイルにするのがベスト。viewで連結しても
結局は，SQLを書く手間が省略されるだけで，スピードが向上する
わけではない。mysqlで全文検索するメリットの一つは，即時更新である。
apache solrだとどうしても，DB更新→インデックス更新となり，登録
したレコードが全文検索でヒットするまでにはタイムラグがでてしまう。
これらの処理をバッチで行うことも運用的にはコストがかかる。
そのため，mysql上ですべてを処理して，インデックス即時更新と
することにした。この処理のために犠牲になるのは，DBレコード
登録時のレスポンスであるが，書誌60万件，所蔵100万件，書架30万件で
テストしたところ，ミニマムなサーバでも問題なく運用できる結果と
なった。
実際には，
１）bib,hol,serのカラム構成を踏襲したindex用のテーブル作成（holx）
２）１）と同じカラム構成となるようにbib,hol,serでView(holv)を作成する。
３）holの要素を基にして，holxを更新するプロシージャ作成
→ 基本，holに対するアクションは，holxの削除→新規登録で処理する
４）メインとなるholテーブルにトリガー(ins,update,del)をセットする。
トリガーは，３）で作成したプロシージャのキックのみ
こうすると，記録用のテーブルからオンタイムでインデックスを作成
できる（メンテナンスできる）。万が一，holxがクラッシュした場合でも
insert into holx select * from holv；
で復元できる。これであれば，障害時の対応もコストが安くすむ。
全文検索用のテーブルのメンテナンスもservlet側で意識する必要がなくなる。
とりあえず，テストは問題なかったので，本番DBでの実装はこの方針で。
mysqlのトリガーはほとんど使ったことがなかった。トリガーはもっぱら
Oracel PL/SQLだったので，戸惑う部分も多かった。
機能的な切り分けはいつも悩ましい。アプリ側での処理はできればユーザー
へのレスポンスに特化させて，データ周りはDB機能に依存させたい。
汎用的なアプリにする場合は，DB機能依存は問題があるだろうが，
今回のサービスは，mysqlを簡単に捨てるつもりはないし，そもそも
postgreあたりに移行するメリットもないと思われる。これまでは，
ある程度の汎用制の確保にコストをかけていたが，今回はそういった
ことはなしで，極力軽く作っていく予定。