Performance Design Tips : @GetDocField 関数

みなさん、親文書の情報を取得するために@GetDocField関数を使ったことはおありでしょう。

例えば、NotesのDiscussion Templateを例に見て見ましょう。

Discussion Templateは子文書に親文書の情報を持つようにできています。

これは子文書作成時に親文書のSubjectなどのFieldの値を引き継ぐ形になります。

では、Discussion Templateで親文書のSubjectを修正したとしましょう。

子文書に保存された親文書のSubject情報は親文書を修正しても、自動的に変更されるわけではありません。

RDBの設計をした方なら、Dataを重複して持たせたくないからと、正規化を行おうとすることでしょう。

Notesの場合、これをしようとして親文書の情報を取得する時には、@GetDocFieldを使うことで簡単に親文書の情報が取得できます。非常に便利な@関数です。

しかし、ここに落とし穴があるのです。

Helpには書かれていませんが、@GetDocFieldを使うと、参照する文書全体をLocal Clientに読み込んでくるという動きをし、必要なFieldだけを取ってきてくれる訳ではないのです。

つまり、もし親文書に膨大な情報が入っていたとしたら、その情報が全てNetworkを流れてしまうことになります。

これでは、よいPerformanceのApplicationとはいえません。

このような場合は、参照する情報を隠しViewに定義して@DBLookupや@DBColumnを使うというのが通常のやり方です。

この方法を取ると、文書全体は取得しなくなるため、Performanceが向上します。

しかしこれでも、Networkの貧弱な環境ではPerformanceは得られないかも知れません。

そういったことから、Discussion Templateは作成時にFieldの値を取得して保持するという方法を採っているのです。

RDBでも同じですよね?正規化を行った後で、わざと正規化を崩すようなことをやります。

論理的に美しい形と、実際にPerformanceよく動くというのは、相反する時もあるのです。

適切に使い分けることで、よりよいPerformanceのApplicationを作ることができるのです。

DominoでBlog? -1-

ここ に紹介されていますが、Notes/DominoでBlogを作成しているProject があります。

このProjectのSite自身が、Domino版Blogテンプレートで作成されています。

Notes/Dominoに関係しているSEとしては興味深々です。早速Beta版をダウンロードして試してみることにしました。

このテンプレートはDomino 6.xに対応しているようですが、私は、Domino 7のBeta版の環境に導入してみることにしました。

動くのかどうか少し不安でしたが、Domino 7でもErrorもなく動いています。

このBlogテンプレートは結構複雑なCodeが書かれた設計なので、これが何もErrorなく動くということはDomino 7とDomino 6.xとの互換性が高いことを証明してくれているのかも知れません。

さて、早速Blogの機能としてどうかを評価してみることにしました。

まず、このAmeba Blogなどとは異なり、このBlogはDominoのDBが1つのBlogを構成しています。

ここのようにWebから一般ユーザーがBlogを作成するということはできません。

Domino Serverの管理者あるいはDBの作成権限のあるユーザーがBlog DBを作成してやる必要があるわけです。

そういう意味では、ここのように一般に広く提供するBlogのProviderを運営する機能が欠けているということになります。

また、Blogの設定などの管理ですが、ここのようにWebから管理を行う機能はなく、Notes Clientで管理する必要があります。

Webを前提とするBlogの世界からすると、少し物足りないような気もします。

詳細は次回ということで、また報告させていただきます。

しかし、こういったProjectがあること自体が重要なように思います。

Techniqueを駆使しているのかも知れませんが(まだ設計の中身を解析しておりませんので、どれくらい複雑なのか詳細は不明ですが、Templateのファイルサイズから判断してかなりの設計要素を含んでいるようです)、Technologyの可能性を試し、色んなMiddlewareで同じ機能を実現してみて、その違いを体感すれば、そのMiddlewareの使い道が見えてくるのかも知れません。

Middlewareと言うのは、単なる道具で、使うのはみなさんです。

誤った使い方をすると不満が溜まるだけですが、上手な使い方をすれば満足されることでしょう。

今時、一から自社向けのソフトを開発するというのは、多分時代遅れですし、コストがかかります。

皆さんも、世にあるソフトウェアを使って業務の効率化を行っていることでしょう。

そんな時、業務の目的に最適な製品を選べているでしょうか?

多分、選んでいる方自身に技術力がなければ適切な物を選べないかも知れません。

ほんの少し、少しだけでいいですから、自分で試してみてはどうでしょうか?

違うものが見えてくるかも知れません。

＜続く＞

BlogとNotes/Dominoの相違点?

前回 は、BlogとNotes/Dominoの共通点について少しふれてみましたが、今回は相違点について考えてみたいと思います。

Blogというのは、Providerが提供するいくつかのパターンを使って、簡単にレイアウトやスキンを決め、レイアウト配置ができるようになっています。

Notes/Dominoなら、Framesetを使って設計をすることになりますが、blogは設計というような感覚ではなく、非常に簡易的にできているというのが特徴でしょう。

IBM製品でも、IBM Lotus Team Workplace (通称 QuickPlace)という製品があり、これはDominoでできたWeb Applicationなのですが、blogと同様にWeb Browserから設定を変更したり、新しいCommunication Spaceを作ったりすることができるようになっています。

では、情報発信する人や参加する人という観点で見てみましょう。

Blogは情報発信する人は実名、匿名どちらでも許しており、読者を制限したりするようなことは基本的にはありません。一部のBlogでは、メールで招待した人にだけ権限を与えるような会員制のBlogもあるようですが、不特定多数に公開するというのがBlogの一般的な使われ方です。

Blogにも禁止IP Addressという機能があり、読者を制限できるのではないか?という意見をお持ちの方もいらっしゃるかも知れませんが、今の世の中Providerが提供するのはDHCPによる動的IP Addressであり、Providerに接続する度にIPは変化しますので、基本的には意味をなしません。

意味があるのは、相手が固定IPを使っているか、相手が企業内からAccessしているような場合です。

一方、Notes/Dominoはどうでしょう?

Notes/Dominoはアクセス制御リスト(ACL)という物があり、Community Space (Notes DB) ごとにアクセスできる人を制限したり、情報を参照する人、情報を投稿できる人、情報を編集できる人というように、権限を細かに設定できるのが特徴です。文書にもセキュリティーをかけることも可能となっています。

Blogも情報登録できる人を追加することが可能となっているものもあります。

このAmeba Blogはその機能があり、管理者が情報を登録できる人を定義することができます。

しかし、この機能ではコメントを制限することはできないですし、コメントの制限は記事単位かBlog全体かの選択となります。

Blogで少し残念なところは、このコメント制限があまりできないことだと私は考えています。

というのも、匿名で勝手にコメントできてしまうと、Blogの世界で「あらし」と呼ばれている人たちにBlogを荒らされてしまうということも起こりかねません。

もし、コメントが書ける人をBlog所有者に制限できたら、もう少し秩序の保たれた世界に発展するのではないでしょうか?

IBMのQuickPlaceも自由にCommunityを提供できるシステムですが、当然この製品もDominoで出来ているためアクセス制御はしっかりしたものになっています。

あと、Notes/Dominoの特徴として、ViewやViewでのコメントの階層表示があります。

Blogではコメントへのコメントという機能はないため、どのコメントに対するコメントなのかを、分かるように工夫しなければなりません。

また、カテゴリー別(Thema別)に見たりといった機能は少し弱く、形式としては昔のBBSに似た形でフラットな時系列の記事書き込みになっていきます。

このあたりがもう少し改善されると、Blogももっと使いやすい物になるのではないでしょうか?

Notes/DominoはViewによって見せ方を変えたり、階層表示でコメント履歴を管理できる面が強みでしょう。

QuickPlaceはカテゴリー表示はできますが、階層表示はできるようになっていますので、Notes/DominoとBlogの中間的な位置付けとなります。

また、Blogの特徴的な機能として、トラックバックという機能があります。

全く異なるCommunity Spaceの他人の記事を参照して、自分の記事を書く機能ですが、この機能により、コミュニティー間の連携を可能にしています。

Notes/Dominoはというと、文書リンクやViewリンクという機能で同様のことが実現できます。

こうして、見ていくと、Notes/Dominoはセキュリティーなどの観点から企業で使われ、Blogは一般ユーザーに使われるという棲み分けができているのではないでしょうか?

しかし、今後、このままの棲み分けが続くとは思われません。

Notes/DominoもBlogもCommunity Toolとして今後も発展し続け、企業ユーザーにも一般ユーザーにも最適な環境を提供していくでしょうし、そうなることを私は切に祈っています。