Performance with readers fields

HCL Domino Domino Forum
1

Hi!I have a couple of questions…

I am designing a database that basically contains two views.

One view will contain one document per user and inside this document there will be two reader fields: One containing the user name (so only this user will see this document) and the other containing the administrator name (so the admin will see all documents).

This view will be sorted by UserName

The problem is that in the company there will be thousands and thousands of users…

In your expierience, each time the user opens the view, will it be slow?

Second question is similar… I have another view with few document (less than 100) and inside each document there will be a reader field with wildcards (like */Organization1)

Where can I put wildcards? I’ve read that wildcards can only be specifed in Common Names and in Organization Units… Can I use it in Country? like

C=U*/O=Org*/CN=*?

Can I filter all users belonging to the same country like

C=GB/CN=* ?

May this second view suffer from performance issues?

Thanks

2

Subject: Performance with readers fields

Pablo, I dont have a answer for yr second question. But regarding your first question i dont think having reader field is going to have bad performance problems.

Raj

3

Subject: RE: Performance with readers fields

Hi Pablo,

If I understant your query:

“One view will contain one document per user and inside this document there will be two reader fields: One containing the user name (so only this user will see this document)”

" in the company there will be thousands and thousands of users…"

Yes, you could get in trouble if you need to display documents that your users have access. If you have, for example, 100 000 users. Domino will have to “scan” every documents to validate if i’m authorize to see them. So, if the only document you can see is in position 99 999, it will be very long.

Look here:

About readers fields, three very interesting documents:

Performance Considerations for Domino Applications

http://www.redbooks.ibm.com/redbooks/pdfs/sg245602.pdf

Notes from Support: Reader Names fields can impact performance

and

technote : Use of ReaderNames fields slows view performance in Notes

Product: Lotus Notes > Lotus Notes > Version 7.0, 6.5, 6.0, 5.0

Platform(s): Mac OS, Windows

Doc Number: 1097609

Published 2006-05-22

JYR

4

Subject: Performance with readers fields

The problem is that in the company there will be thousands and thousands of users…In your expierience, each time the user opens the view, will it be slow?

Probably. When opening a view with docs that contain Readers field, Notes goes down the view until until it has 30 docs the user can read, or reaches the end of the view. If there were a whole bunch of docs the user can see, no problem, but if there is only one Notes will have to troll the whole view every time. Speed will be affected, how much I don’t know.

Plan B

I don’t know if there is a way around this, but here is what I would try as plan B if you get real performance problems: Instead of showing the user the view, show them a frameset instead. Arrange to have the frameset display their document using a Notes URL. Compute the url using DbLookup: Do a DbLookup against a view of these same docs, sorted by username; have the doc unid in column 2. If the doc exists, pull back the unid and use that in the url:

Notes://server/replicaid/0/documentunid

If the doc doesn’t exist, display something else.

Of course you might have the same performance problem b/c you are still doing a dblookup against docs with Readers field. But maybe the dblookup would run faster than opening the same view? And anyway the user just wants to see their own doc, right?

Plan C

A variation on this idea is to have the user’s doc push its own unid and username into a separate document, one with no Readers field. Use the PostSave event for this. Do your DbLookup against these docs. Make sure, if the user docs gets deleted, the keyword doc gets deleted also.

For the admins, check for the [Admin] role in your formula and have the frame display the view instead, skipping the whole dblookup thing.

I don’t know about your second question.

5

Subject: Performance with readers fields

As far as the second question …categorize by country.

6

Subject: Have you looked at profile documents?

If I understand you right, you want to create a large number of user-specific documents, each of which can only be read by the named user and by an administrator (so you don’t lock yourself out).

I’m thinking that you want to store some user-specific settings for the database. The usual way to do this is by using user-specific profile documents. You can read more about this by searching for “Profile forms” in Domino Designer Help. These profile documents don’t show up in views, so developers don’t typically bother to protect them with Readers-type fields, but you certainly could do that if the info is confidential.

The big advantage of profile documents is that you can access them simply through Formula language (such as @CommandEditProfile) and LotusScript (such as UIWorkspace.EditProfile or NotesDatabase.GetProfileDocument).

There may be good reasons why profile documents don’t meet your needs, but they’re worth a look.

As to wild cards, I’m not sure if I know the definitive answer, but I’ve only ever used them (or seen them used) on the left side of a name expression, e.g. */MyOU/MyOrg and */MyOrg, but not /MyOU/ or /MyOrg/. Also, I’d be suprised if there’s any way to get them to work by replacing just part of a name element – I think the * has to stand for the whole CN or OU value.

Rupert Clayton

London

7

Subject: RE: Have you looked at profile documents?

I have heard there’s a limit on the number of profile docs you can put in there, and that this limit is about 1000. That’s why I didn’t suggest profiles. You know anything about this?