我正在努力想出一种实现自定义文档表单的好方法。
这是一个请求访问应用程序的工具;每个应用程序都想询问自己的具体问题。问题是，我们有一种（普通）用户需要填写并提交基于模板的文档，另一种（超级）用户需要能够定义每个模板需要包含的内容。
一个实现选项是使用表单（具有基本的强制性内容），并使该表单动态地包含适合于手头特定任务的子表单。问题的关键是我们可以（=将！）很容易地结束数百个不同的子表单！
（注意：这些子表单将以自动方式维护，但another topic可能被认为超出了本课题的范围。）
众所周知，在Notes数据库中拥有大量视图是Bad Thing。但有没有人试图推动表单或子表单的数量，并提出任何有关性能的经验？
答案 0 :(得分：1)
我没有把它推到那种限制，但我做了类似的几十个子表格。我不认为这是一个真正的问题，就像有很多观点一样。
也许如果您一次在一个表单中插入数十个或数百个子表单，可能会遇到问题，但只从数百个池中选择一个或两个子表单不应该导致问题。在我看来，这是接近设计的最合理的方式。
视图是个问题的主要原因是它们的索引。每个视图都维护其中包含的所有文档的索引。然后，对于该视图中的每个列排序，索引大小加倍。真正的问题是维护和资源。您拥有的视图越多，Notes重建索引的工作就越多，重建所需的资源（磁盘和内存）就越多。