IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

A performance question came up after my presentation today which I thought I should address with a blog entry. This has to do with the database option "Don't support specialized response hierarchy" and the associated functions @AllChildren and @AllDescendants.

"Specialized response hierarchy" refers to an internal table stored in the NSF that lets Notes quickly locate all the responses to a specified parent document. Without this table, functions that require this ability -- such as the above-mentioned functions and the NotesDocument.Responses property -- simply do not work. Instead, they act as if the document had no responses. Of course, it's extra work for Notes to update this table every time a note is modified, so it's better to turn the option off if it's not needed. But how do you tell when it's needed?

Let's take a sample application containing one main form, and one response form. You want a view that shows the main documents whose status is "Unfinished", and also their responses. Without using the responses table, you could write the following selection formula:

SELECT (Form = "Main" & Status = "Unfinished") | Form = "Response"

I'm assuming that the response documents do not contain any field value that would let you tell whether their parent is in the view.

To do the same selection assuming the specialized response hierarchy enabled, you might write:

SELECT (Form = "Main" & Status = "Unfinished") | @AllResponses

On the face of it, there seems to be no differences between these two approaches. In either case, only those responses whose parents are in the view, are visible.

However, it's not quite so simple. Suppose there are 100 main documents and each of them has one response, and suppose 20% of the main documents are at "Unfinished" status. In the first case, all 100 response documents are also in the view, even though most of them are not visible. They're in the stored view index, and you can find them with a full-text search. So the index contains column values for 120 rows of data.

In the second case, the view index contains only those responses whose parents are also in the view. That's 20 main documents and 20 response documents, a total of 40. So the stored view index is smaller, and probably takes a lot less time to calculate just because fewer documents must be inserted into it.

Incidentally, you can see the size of the view indexes using Domino Administrator, if you want to try a test and compare for yourself.

Also consider what happens while the first view is being indexed -- imagine yourself in the situation of the view indexer. You're handed documents in random order, and you have to insert them into the index at the appropriate position. Every time you find a response document, you have to search the view for a matching main document (one whose UNID matches the response's $REF). Locating a document in a view by UNID is pretty fast, but it's not instantaneous.  Also, if you find a response document and don't find the corresponding main document, you have to insert it somewhere in the index anyway to keep track of it until the matching main document does turn up, if that ever happens.

When using @AllResponses, on the other hand, it's not necessary to search the view for a main document matching a given response, or vice versa. That's because when you find a main document that should be in the view, you can immediately grab all the responses from the internal "response hierarchy" table (a quick search because it's sorted by UNID), and they can be inserted into the index immediately following the main document you just added. If the first part of the selection formula matched any response documents, you would still have to insert them provisionally until their parents turned up, but in this example that's not going to happen (much -- if there's a replication conflict document it could end up that way).

So that sounds like less work. I haven't tested it, but it seems reasonable -- don't you think?

Andre Guirard | 23 April 2009 06:00:00 AM ET | DanNotes Conference, Denmark | Comments (5)

Search this blog 

Disclaimer 

    About IBM Privacy Contact