_ Oracle World行けず

忙しくて、楽しみにしていたOracle Worldに行けず、残念です。ここ一ヶ月、ベンチマークテストをいろいろとやっていたのですが、そのレポートも今週でほぼ書き終わり、ほっと一息です。

10gの詳細も知りたかったのですが、ガッツ石松のインストールも見たかったです。元世界チャンピオンに対してなんという扱いをするのかとも思いますが、Oracleのマーケッタは粋な企画を考えます。

_ WEB+DBプレス vol.18

さっそく見つかったか(笑)。裏表紙に広告を出しているので、記事広告を載せられるのです。仕事で書いたのですが、ページ数が少ないので、ネタ探し＆書くのに苦労しました。

_ Domain Logic and SQL by Martin Fowler

示唆に富む記事です。Transaction Script、Domain Model、Complex Queryという命名が面白いです。なるほど。

私は最近O/R mapping toolに懐疑的で、コードにSQLを含むこと自体は悪くなく、SQLを含んでなおmaintableでtestableな書き方を探すのが本来なのではと感じています。

一番のchallengeは、データサイズが数十GB以上など大きくなったときです。数百MBのデータならApp Serverのメモリに入るのでin-memory approachで問題ないのですが、そうでないときは（そしてそれがEnterpriseの現実でしょう）、効率的なSQLを人間が考えねばなりません。

O/Rツールだと、それができないものもあるようだし、できてもDisk I/Oになってしまうようだし、結局はSQLです。

大きいデータベースの場合、App Serverのキャッシュも有効か疑問です。キャッシュヒットは期待できず、かならずDisk I/Oが発生します。そこで、きちんとIndexを使うようにSQLに気を配らなければなりません。そもそも、データベースにキャッシュがあるので、さらにApp Serverがキャッシュを持つのは、車輪の2度発明な気もします。

そこで、究極的なO/Rツールは、動的にクエリやキャッシングを変えるものだと思います。つまりコストベースです。データベースのデータ量などに応じてやりとりを変えないと、大きなデータには対応できないでしょう。今のO/Rツールは、いうなれば旧来のルールベースであり、コストベースへの技術革命はだいぶ先でしょう。データベースのオプティマイザの部分もO/Rツールが担うことになるからです。

うん？そうでもないか。App Serverは同じクエリをながせばよく、それを最適化するのはやはりDBの責任か。うーん。いや、関係のあるものすべてを取得するかどうかのオプションがO/Rツールにすでにあるので、それを推し進めたものが究極の姿か。OOの関係だけ人間が定義して、必要なデータを必要なだけ取得するようサーバのデータ量に応じて姿を変える。うーん。

ところで、題名の記事に戻って、FowlerさんもRubyなのね。Ruby好きは知ってたのですが、こういう記事でRubyをサンプルにしてしまうのが驚きです。

_ CATVモデムがハング

今週サーバが不安定なのは、CATVインターネットを利用するためのモデムの調子が悪いからです。モデムが突然固まり、電源リセットが必要になります。こういうことは今までありませんでした。CATVモデムは、上との接続を覚えていたり、クライアントのMacアドレスを覚えていたりするので、内部側のLANケーブルを取り換えるときは、電源リセットが必要です。でも、物理的な変更は何もせずに突如固まるというのは不可思議です。

ネットで検索したら、2chにCATVスレがあって、同じ現象に悩んでいる人がかなりいました。情報公開なく、どうも11月下旬からネットワークを更新しているようで、P2P規制も秘密裡におこなわれているようです。私はP2Pしないのでそれは関係ないのですが、ネットワークが不安定になるのは困ったなぁ。

USENが結構人気のようです。