In a past life I had to deal with trying to find member sizes for various reasons.
1) To understand what the space requirements would be for a member (and ultimately a sandbox) should someone try to create a sandbox. At that time, sandboxes had the potential to be huge, and having the total size was going to be used to help identify which automated build servers had enough capacity to handle the sandbox create and subsequently build (we used a rough formula to understand the output size vs. sandbox size). Based on build server availability we would either select a target build server with the required space, or generate a new one to build on.
2) We also wanted to look for discrepancies between member sizes relative to the size of change required. For example, if someone were making a code change to alter a color code, we wouldn't expect to see a member difference measured in MB. At the time we had outsourced a considerable amount of work and had internal people accepting the changes as they were sent back. This was an attempt to locate anything that seemed our of line with what was requested so that we would know to look further. Basically, a high level reasonableness check given what was being asked for.
3) Large binary checkins for selected projects could only be performed by certain people. The intent was to inform users before they attempted to check in what their particular size limitation would be for that project.
We were very close to being able to manage the first two cases, but it wasn't an obvious approach. At checkin time, it was possible (and for the life of me I can't remember how I did this) to capture the incoming size of the member somehow, but only after it was received by the server. Once there, I stored the file size as an attribute on the member (checkin-pre trigger). Since revisions didn't/don't support attributes (boo!) I ended up with my own naming convention within the member attributes to store the sizes of each of the revisions. It wasn't pretty, but workable.
For option #3, the trigger approach wouldn't work. The file size wasn't available until after the file had made it to the server. So for scenario #3, we were out of luck for preventing users from sending large files until they had already sent it and paid the price for the network overhead and time. When some of the binary files being checked in measured in 100's of MB, the upload time could be quite significant. We approached this in another way using a subproject structure and permissions, which was tedious but acceptable.
Instead of storing everything with the member, the alternative approach that we had considered was to create a separate database and table for this type of information, and then use triggers to glue everything together. After some consideration, we decided that this would provide too many headaches for backups, DR, overhead in triggers, etc, and thus abandoned the idea. However, from time to time, this does come up when we find that we have data that deserves to be stored elsewhere. With our new approach of offloading trigger work to external servers through web services, this approach could now be much more feasible.
All of this was years ago, and getting harder and harder to recall... Thankfully.
