From various posts here it seems that the number of documents has more effect on performance than db size. Does anyone have any thoughts as to what would be the top end for a reasonable maximum number of documents?
I have been asked to look at a project where data from DB2 would be pulled into Notes via LEI. Each record relates to a customer, with possibly up to 8 million customers. There is a possibility to split this across a number of separate Notes databases. What would be an acceptable number of records in each to avoid the indexer or the server grinding to a halt?
Subject: Maximum number of documents
Martin,
There is no real max but of course at a certain point you may have a performance bottleneck around indexing, as you point out. It really is going to depend upon how many edits/hour you have and how much other work your machine is doing.
It is certainly possible to make an app with 8M records and have it run smoothly, but you’d have to prioritize performance when implementing features.
sorry this is so generic,
raphael
Subject: RE: Maximum number of documents
Raphael,
Thanks for your reply. I realise there is no easy answer to this question.
The documents in this app would only be updated by LEI - possibly on a 4 weekly basis. Some users would access the nsf on the server for querying the data. Other mobile users would have local replicas with a subset of documents, based on Readers field. I guess this could prove another problem in the length of time needed to create the replica initially.
Thanks again for your reply.
Martin
Subject: RE: Maximum number of documents
Martin,
I imagine that replication times could be very long for your mobile users because the replicator needs to run through 8M doc ids.
regards,
raphael