I'm in the following situation: I've been burdened with a table, keyed on recipient, and report. That key basically defines which user has read access to which reports. OK, so far so good.
The problem comes in when years later, the table has ~16 million records in it, and administration is a nightmare. I need to programmatically divine what groups might be appropriate by looking at which reports are most commonly asssinged to which people (ie: by looking at the report-recipient relationships, make a SWAG at defining a reasonable 'Accounting' group, or maybe 'Sales', etc.). IOW, which groups should I create to efficiently reduce the greatest number of report/recipient relationships?
Coding up the group mechanism isn't so bad. I just need a way to go back and populate the new groups table. (FWIW, I looked into Debian's AutoClass package, and that doesn't seem to be quite what I need, but I don't exactly have a Masters in Math either.)
So, essentially, I believe this is a vocabulary question, or perhaps I'm asking for a 'group identification' algorithm.
Thank you for your time and kind consideration.
In reply to Group Identification by pboin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |