db Lotus Notes 的大小
我需要关于高度不稳定的 db Lotus Notes 最大大小的建议，即基于 8+ Gb 数据库的应用程序，平均由 20 个用户访问插入附件和运行脚本。
谢谢！
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我需要关于高度不稳定的 db Lotus Notes 最大大小的建议，即基于 8+ Gb 数据库的应用程序，平均由 20 个用户访问插入附件和运行脚本。
谢谢！
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
Notes 数据库的大小是有限制的（对不起 Ken）。请参阅 Notes 帮助“Notes 和 Domino 已知限制”和 Technote #1308379。
最重要的是：
通常应用程序的“限制”因素是视图重建和全文索引时间，正如肯建议的那样。
您可能需要查看 Andre Guirards 关于性能主题的帖子以及他的白皮书IBM Lotus Notes 开发人员的性能基础知识 和 Domino Wiki。
There are limits to the size of a Notes Database (sorry Ken). See the Notes Help "Table of Notes and Domino known limits" and Technote #1308379.
The most important ones are:
Ususally the "limiting" factors for an application are view rebuild and full text index times, as Ken suggested.
You may want to checkout Andre Guirards postings on the topic of performance as well as his white paper Performance basics for IBM Lotus Notes developers and the Domino Wiki.
我不确定这是否能回答您的问题，但理论上 Notes 数据库的大小没有限制。几年前，我记得在 Lotusphere 听说他们测试了一个 64GB 的数据库并且它有效。
也就是说，视图索引变大可能会出现一些问题，并且刷新视图需要等待很长时间。
I'm not sure if this answers your question, but there's theoretically no limit to the size of a Notes database. Years ago I remember hearing at Lotusphere they had tested a database at 64GBs and it worked.
That said, there will likely be some issues with view indexes growing large, and long waits for refreshing views.
在下面的链接中，您可以找到与 Lotus Notes 数据库相关的限制，因为它们来自 IBM，也来自 leyrer。
Lotus Notes 的局限性
然而，在我们公司，我们大量使用 Lotus Notes 数据库，并且我们的数据库增长非常快，主要是因为附件可以是文档、电子表格、图像、为了避免达到大小限制，我们实施的解决方案是正常使用应用程序并将附件附加到其数据库。这样，附件不会存储到主应用程序，而是存储到附加数据库。您可以创建尽可能多的。例如，您可以具有以下内容：
通过这种方式，我们还可以控制数据库的增长量。我希望这对您的实施有所帮助。
In the link below you can find the limitations that concern the Lotus Notes Databases as they come from IBM and stated also from leyrer.
Limits of Lotus Notes
However, in our company we are working heavily with Lotus Notes databases and our databases our growing very fast mostly due to attachments that can be documents, spreadsheets, images, etc. The solution that we implemented in order to avoid reaching the size limits was to have normally the application and attach to it databases for the attachments. In this way the attachments are not stored to the main application, but to the attached dbs. You can create as many as you can. For example you can have the following:
In this way we can also control how much the dbs will grow. I hope that this can help you in your implementation.
对于大型数据库，一旦不再积极处理文档，考虑归档文档的策略可能很重要。你没有提到每天创建/编辑/删除多少文档，或者平均文档有多大；但如果现在是8GB，下个月或者明年会有多大？根据 martin 在他的回答中列出的因素，在您达到 64 GB 支持的限制之前，这可能会成为一个问题，并且最好提前做好准备。
For large databases, it may be important to think about a strategy for archiving documents once they are no longer being actively processed. You don't mention how many documents are created/edited/deleted every day, or how large the average document is; but if it is 8GB now, how large will it be next month, or next year? Depending on the factors martin listed in his answer, this could become a concern long before you reach the 64 GB supported limit, and it is better to be prepared in advance.
第一个建议是，创建一个存档数据库并减少主数据库的大小。在下一步中，您应该编写一些流程，以便根据您的需要每周或每月归档文档。
First suggestion is, create an archive database and reduce the size of the main database. In the next step you should write some process in order to archive the documents weekly or monthly according to your needs.