It's no surprise that I am rewriting the event system here on clux.org for deathmat.ch. But I actually want this site to become popular, and I have a pretty good feeling that the current SQL table solution that required numerous joins to get each event up would scale very badly. So I started looking into database alternatives; 'tis the season.
MongoDB is my final choice. It is invigorating to deal with tree-structured data rather than joining layer upon layer of SQL tables to essentially do the same thing per request - and after having professionally programmed in C for half a year, you learn that shuffling bytes and bits around is essentially all you do, so it becomes paramount to use the right structures for the shuffling. It does force you to think in more detail about your plans of usage to get the most out of it, but fortunately, I know exactly what I want to build. I can already do a lot of cool stuff that I could only dream of in MySQL - or which would at least kill the excitement of doing it knowing that this will never work for more than a small user base.
An example of my usage is my tournament table which embeds a list field with all the matches which embeds a players short nickname - instead of having to join on each of the matches that I need to get for that tournament, especially since there is not much I want to do with those matches outside that tournament anyway. The downside is that all players' nicknames are duplicated a bit, and possibly will change, but that is also a pretty accurate reflection of what players do after years of gaming. I have settled for locally unique nicknames (per event) and globally unique usernames. This also allow me to more accurately use placeholders for players who are not (yet?) members, so that they can search through events for their used local nicknames and claim them with tokens or requests.
Other good features of MongoDB include easily configurable replication and sharding if future scaling needs should arise. Oh, and since the drivers doesn't concatenate query strings, you won't get injection attacks either. Useful in
today's world. The biggest negative I've found is that you'd have to program much of transactional queries yourself (as is the case with
ACID requirements and NoSQL; you tend to have to sacrifice something for performance). It can be done
with extra queries, but hopefully I can order things in such a way that I wont have to do many of them.
Prepares to eat own words in 6 months
