Wedge

- Custom membergroups: this one is harder because it has so many ramifications. I'm going to try and address most of them. So,

1/ Add an id_owner (id_member) field to the membergroups table.

2/ Add an interface for users to create membergroups.

3/ Add more membergroup types. Things like 'hidden' and such are good

4/ Add more membergroup fine-tuning. This is a thing I have in Noisen and am really fond of -- I can determine whether people can see all or part of my friends list. Some of my friends I chose to keep in a 'hidden' state so that they would benefit from being in my friends list, without being visible as one of my friends. Perhaps this could be 'simplified' (for code) into two groups: a regular 'friends' group and a hidden 'friends' group... I'd rather have an extra field for that, though. And it's just an example.

(a) Write some UI for group selection in privacy settings. Not too complicated when it comes to setting privacy from the posting page, but I also want to be able to set privacy on the fly through a select box, like I'm doing on Noisen.com (although it's not a select box there, it's actually a rewrite of the icon selector). The difficulty is not in writing the thing, but in making it so that it's *easy* to understand and use.

(b) And the single most frightening thing for me... Dealing with the aftermath of being able to create membergroups for anything. Basically, from my experience on Noisen, I know that people aren't going to spend their days creating membergroups, but if they end up doing it, it could easily break Wedge if not handled correctly. Do you remember when Facebook had a limit on how many friends you could have? I think it was 5000. It was a lot though, and I doubt any forum would be penalized by having such a high limit on the number of friends. I'm still going to assume that 10k users are going to add Mike42 to at least one of their membergroups, and Mike42 is going to add 10k users to his own 'friends' group (reciprocal friend additions -- that'd be asynchronous in Wedge, i.e. not mandatory, unlike SMF.)

So, we have a members table where the additional_groups field for Mike42 contains 10k comma-separated group IDs... Which probably makes it even impossible to store additional_groups into a TEXT field. (I guess MEDIUMTEXT would do...)
Even then -- it's going to kill performance, whatever we do about it. So we need 3NF for membergroups too. We discussed it at length but, yet, nothing has come of it. I'm getting wary of it, Pete is getting wary of it... I even recently read an old discussion on sm.org where Pete (yes, you Pete :P) actually discussed how 3NF could kill performance if table joins were used everywhere.

Now we have 3 ways of dealing with this... Either we just set a (relatively) low limit on the number of people you can put into a custom membergroup, and/or number of groups you can be put into, in which case I guess staying with the current SMF way of doing things is all right, or we add 3NF and still keep the additional_groups field and up the limit (but not too much), or we do it entirely 3NF and get rid of additional_groups, get rid of any limits and scream at the performance issues later...

I'm not going to get into the meat of things here, because there's a lot of things that this impacts on, but I will take care of the issue relating to 3NF.

There are times and places that normalised data can have performance concerns. (And really, 3NF is tame. Wait until you start dealing with 5NF. :niark:) Like everything else, that is.

Now, a lot of my concern about normalising everything is that you end up generating far more rows in a resultset than you need or you start getting more queries, and for information you're loading at certain times, it's going to get hideous.

I actually have an example in SMF for this: board level moderators. They're stored in their own table, and during the board index gathering query, they're actually pulled via join into the main query. Now, on a forum without any board level moderators, it's not a problem. But if you have one board with 3 moderators, that board is returned three times, once for each moderator, which has to be cleaned up in PHP, and that accounts for some of the overhead attached to the board index stuff (which is, indirectly, one of the reasons the sub-board-of-a-sub-board problem occurs).

In that particular case, I'd almost argue that having board moderators would almost be better handled as a comma-separated value stored inline in the board table, precisely because there aren't many of them in most cases.

Getting back to the concern here, separating out friends to another table will give you the proper asynchronous structure you want. But it means that loading the list of friends up front is not cheap, because it means either overloading the first query where mem.* is loaded (which for any number of friends is non trivial), or we add a new query at that point, or we push it into a cache.

That said, we can consider a few alternatives... where exactly do we need to know and care about whether a given user is a friend of ours? Well, for the users online area in the footer, certainly, but with an asynch table we can actually do a join from *that* query and figure it out that way. For the PM area we can do a query as needed there, and so on.

Like everything else, it's a change, but it can bring other changes to balance it out.