Why would 1.000 subforms in a db be a bad idea?

Warm-up

I'm trying to come up with a good way to implement customized document forms.

It's for a tool to request access to applications; each application will want to ask its own specific questions. The thing is, we have one kind of (common) user who needs to fill in and submit documents based on templates, and another kind of (super) user who needs to be able to define what each template needs to contain.

One implementation option would be to use a form (with the basic mandatory stuff), and have that form dynamically include a subform appropriate to the specific task at hand. The gist of the matter is that we could (=will!) quite easily end up开发者_C百科 having many hundreds of different subforms!

(NB. These subforms will be maintained in an automated manner, but that is another topic that may be considered outside the scope of this Question.)

Question

It's common knowledge that having a lot of views in a Notes database is Bad Thing. But has anyone tried pushing the number of forms or subforms and made any experiences regarding performance?

I haven't pushed it to that kind of limit, but I have done something similar with dozens of subforms. I don't see that as being a real issue like having lots of views is.

Perhaps if you were inserting dozens or hundreds of subforms into one form at a time, you might run into a problem, but just choosing one or two subforms from a pool of hundreds shouldn't cause an issue. It is the most logical way to approach the design in my opinion.

The reason views are an issue is mainly their indexes. Each view maintains an index for all the documents that are contained within. Then for every column sort in that view, the index size doubles. The real issue becomes one of maintenance and resources. The more views you have, the more work it is for Notes to rebuild the indexes and the more resources (disk and memory) required to rebuild.