This content has been marked as final. Show 3 replies
The main thing to remember is that the sheer number of accounts is not the main security concern, it's the overall access to those accounts.
For example, let's say you have 100 accounts in the system and each person only has access to 1 account each. Searches for content would then only need to query on each individual account
"AND dDocAccount Matches "xxx""
Likewise is the sysadmin does searches they are not restricted at all, so no additional security clause is added.
However, if a manager does a search and they have visibility on 45 accounts then you can imagine what the security clause would be on that query?
AND dDocAccount Matches, AND dDocAccount Matches, AND dDocAccount Matches, AND dDocAccount Matches, etc
So the scalability is usually influenced by how much access will be needed to those accounts.
But do remember that the account permission is heirarchical so if you know that a person will need access to a bunch of accounts try to design the model so it will allow you to move that person up a level hence grant access to multiple accounts in a single dAccounts= statement.
Also try to simplify access to information that is actually public in nature. Don't use it just to segregate content by say a department. Use a seperate metadata Element to designate the organization.
Much of what most organizations have is actually public internally, or should be unless there is a compelling legal reason for it to be secret. So create a high level group like /Public that everyone has read access to and then creat sub accounts that their department can write to like Public/HR.
But also remember that accounts is like a 30 character field so keep you design compact unless you intend to change the datatype.