Looking for thoughts from others…
Building an XPage solution that allows people from different departments to use the exact same application but their data needs to be isolated into separate nsf files.
Which do you think would be better for performance? Make each of the applications present their own data (so each XPage application would be separate nsf files) OR make one XPage application and that retrieves the correct data as needed from the separate nsf files that contain their data?
Subject: Thank you and some test results…
Thank you John for your input. The issue with the standard design template route is one of web server redirection. We have a single dns entry and we would like each department to end up at the home page for their application no matter what bookmark they may have stored while using their own copy of the app. I might have that solved but I figured if performance was not an issue then a single nsf file would eliminate the redirect challenge.
I ran some Page Speed tests last night on very small data sets and only using one application and I found very slight performance degradation by using a remote datasource to display content in a standard view control and creating, editing and saving a document through a second XPage. By slight I mean saving went from 2200ms to 2600ms. All of the operations were almost identical.
Subject: My thoughts
For performance, I think it would be better to go with a single XPages database that goes after the correct database source because then you only have one set of XPages data compiled and loaded in server RAM.
That said, I wouldn’t do that. I don’t think the performance boost would justify the added complexity. It would be easier and more flexible for each of the databases to inherit from a unified design template.
If there was anything like a logo or custom control that was specific to one department, you can take care of that through prohibit design refresh.
Moving the apps around (e.g. local replicas) becomes easy because each db is all inclusive.
Easier for new developers to understand.