_ この週末は (12:18)

リアル引っ越しで忙しくてネットにつないでいる暇がないんで、そんなときにあんまり面白いことはしないでください。おながいします。

_ SBMをシードにした検索エンジン

いつのまにかHyper Estraierにクローラーまで追加されて、Hyper EstraierだけでWeb検索システム一式そろうようになっていた。1470.netをリニューアルする際に、今度は検索周りをどういう風に作ろうかいろいろ考えていたんだけど、実はSBMで登録されたURLをシードにして、Hyper Estraierのクローラーに巡回させるだけで、十分面白いコンテンツになりそうな気がする。ブックマークすると、Hyper Estraierが関連情報を勝手に集めてきてくれる感じ。バックエンドはHyper Estraierに任せて、あとはUIに凝ればいい。個人（ローカル）でそういうシステムを動かしても便利だろうね。

_ Zend_Db_Tableを使った場合の、DB負荷分散への対応

Zend_Db_Tableを使って検索系クエリーを複数DBバックエンド（レプリケーション）に（コードレベルで）分散したい場合ってどうすればいいんだ？　一応setDefaultAdapterで適当にDB接続を切り替えてから、Zend_Db_Tableオブジェクトを生成すれば、そのオブジェクトでは生成された瞬間のZend_Db_Adapterを維持してくれるみたいだけど、複数のZend_Db_Tableオブジェクトで同じZend_Db_Adapterを使っていることを保証したりはできないよなー。更新系アプリと検索系アプリを分割し、検索系アプリでは全体で接続先を分散するようにする？　あるいは基本的に接続先を分散しつつ、更新系処理を行う部分だけは明示的にマスタに接続させる？　あるいはコードレベルで対応するのはあきらめて、DBレイヤーに近いところで負荷分散させる？（SQL Relayとかpgpoolとか）　RoRとかではどうやっているんだろう？　まだざっとしか読んでないけど、「RailsによるアジャイルWebアプリケーション開発」にはその辺ことは書いてなかったよなー。

ちなみに

DB_DataObjectでは、$do->_database_dsnをいじって、オブジェクト単位でDB接続先を変えれば、そのオブジェクトを通した処理は、すべてそのDB接続先に対する処理になるから、それで一応管理できた。Zend_Db_Tableの場合は、基本的に1テーブル単位の処理しかできないから、複数テーブルにまたがったjoin相当の処理をしたければ、複数のZend_Db_Tableオブジェクトを作る必要があり、それらが別のDBに接続されてしまうと、話がややこしくなる。っつーのをどうしようかなー、という話ね。