Board Surveys

[Bob Zumbrunnen]

http://www.investorshub.com/boards/board_surveymenu.asp?board_id=238

Survey #5 on that board is a good one. I'm kinda curious to see the results, although it's doubtful survey results will change my philosophy about showing how many people have someone ignored.

Not only do I have a philosophical problem with that, the way filtering works doesn't lend itself to easy tallying of how many times a particular person shows up in the filters. I wrote a system to calculate the totals for each person and had considered posting a one-time "Most Ignored" list but not only didn't like the "negative energy" aspect of it, I also didn't like how hard the database server had to work to produce the list and knew I could never get away with posting it only once.

And it'd be a helluva workload if that same basic query were run everytime a Profile screen were pulled up. It's the 5th most frequently used routine on the site.

For those who're technically inclined, filters are stored as a string of numbers (account numbers) separated by commas. Each user who uses the filtering feature has a record in the filter table and their filterees are part of that string.

When the user reads messages, his particular filter record is pulled up and the author number of the next and previous post is compared with that user's filter string. If the author (or recipient, if that filtering option is enabled) is found in the filter string, the system skips that message and goes to the next one and does the same check again until it finds both a Next and a Previous message that aren't filtered out.

As you can imagine, that can be a pretty expensive process. And that's when pulling up only one filterer's filter record.

If I implemented something like that in profiles, the system would have to step through *all* filter records and see if that user's number occurs in any filter strings and tally them up if it does.

That processing would happen on every profile, even if nobody ever placed a filter on them. Granted, the overhead wouldn't happen on a non-filtered person if I added a field called "is_filtered" or something like that to the member table and only call the filter-tallying subroutine anytime that's set to true, but doing that would add the overhead of updating that anytime a filter record is modified or someone turns their filtering on or off.

Even in that scenario, any profile that was filtered even once would still have to process every single filter record. Very, very expensive. Especially when done thousands of times per day, which is how often the Profiles routine is used.