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を作ることができるのです。