Question

We have a system which has complex user permissions which determine which contacts a user can see in the application and I am looking at the best way of structuring the tables to enable us to scale. The permissions are too complex to work out on the fly so need to be written to a table which will then be updated whenever admin functions are performed or a contact is added/edited/deleted.

The contacts table has 10 million records in it. My first thought was to create a contactUserLink table which would have contactUserLinkID,contactID,userID with the clustered index on contactUserLinkID and a non clustered index on the contactiD and userID for quick searching on.

My concerns with this are this:

1. If we had 200 users and they all had different access to large parts of the data the contactUserLink could balloon to 100s of millions of rows.

2. There would be a lot of adding / editing / deleting going on in this table as contacts were edited and admin changes on the rules occur.

3. Admin changes could lead to huge amounts of deleting / inserting as user permissions are re-worked which if they took a long time could leave users with no access.

4. If a new user is added and he has access to all the records writing 10 million records into that table isn’t likely to be fast?

We are using SQL 2008.

I hope I have managed to explain that so that it makes some sense.

Any help on this would be greatly appreciated.

Answer 1

This sort of granular user permissioning is not ideal. As stated in #4, writing a 10 million records to give an admin access to all contact is most definitely not scale-able. Have you tried looking into role based permissioning? Is this an option in your scenario?