If you're using security roles as people have discussed earlier, the brunt of the cost will be at share time, but it's almost free at query time because it's baked into the indexes. The cost at share time is that for every doc whose view you're changing you need to rewrite that doc. Cost will be similar to loading the doc the first time. Having lots of roles in the database is fine, except you'll want to avoid the admin GUI which will choke spitting out all that html. Same with having lots of users.
Here's another approach nobody has mentioned: Use queries to define each user's view. Basically construct a definition for each user of what they're entitled to see. To share with them you change their definition. The definition should include their own files (which can be defined via security roles or directory paths or a collection per user). Doesn't matter. Then for the second part you define a query (say, written out as a persistent document) for each user of what special stuff they're entitled to see beyond their own. Users which don't have anything shared with them (I assume that's the common case) can have no document (meaning no expanded view). During all query execution and document retrieval you OR their normal view with the expanded view. You can register the combination query to make it fast on subsequent executions. So Alice logs in. Nobody shared with hem. So you run her search either confined to her security role, an /alice/ path, or an "alice" collection. Now Bob logs in. Some people share individual docs with him, others maybe share whole collections. So you run his search confined to his role/path/collection and OR that with the cts:document-query() or cts:collection-query() from his definition. Sharing to one user is fast even if you do a big share to him/her because it's one document to update. If you're sharing in standard groups then sharing collections makes it easy to express as well. Sharing 10s of thousands of URIs with someone will be cumbersome but with registration could be acceptable in performance. Sharing the same doc with 10s of thousands of people will be cumbersome due to lots of small writes. If you're doing that though, you probably have some group-level concept, and can expand my design so each person has a user and group query definition of what they should see. Now let's talk minutia in design: If you're willing to trust future developers to remember the security rules, I'd recommend you use a collection or directory per user and skip the overhead of making roles. Put some nice function calls in front of all this and you're good. Fast updates, fast performance, design hidden by libraries. If you *don't* trust future developers and think they might forget to check perms when retrieving a doc even though you gave them handy functions (how many times have I seen that), then you can make it so the regular nobody user can't see any docs and has to run an amp'd module code to do document access for search and retrieval. That amp'd code isn't maintained by the untrusted developers. That's more complexity, but lets you "bake into" the system the rules in a way that's hard to go around. -jh- _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
