Hello forum!
I’m working on a tournament app, it is a knock-out that can be of 8 , 16, 32 or 64 players. The way I built it in order to be scalable (I think) is to have a data type of “tournament positions” (besides the tournament datatype I have), in which each data record has the position within the KO layout and the torunament it’s part of, and also adding a field of “disputed position”, which is the position that the player will be fighting for on current match against the other position that has the same “disputed position”. For example, let’s say it’s an 8 player KO, so the first round is quarterfinals, so the position QF1 is the player who is in that position, and will dispute the position SF1 (semifinalist 1) with the QF2 position, so the QF2 position is a different player but has the same disputed position (SF1). Once that match is played, it will send a new record to this positions type with the player that won , the position achieved/won (SF1) and the new disputed position (F1), then, this player wil play against the winner of the position QF3 and QF4, which would be the semifinalist 2 (SF2). Given this context, my questions are the following:
-
I did it this way as I though it could be the most scalable way to build this as I can have a backend trigger that creates the new pending match (which is needed to add a score) once there are 2 records in the positions datatype with the same “disputed position” in the same tournament. Is there any other way you cant think of to build the database the makes it scalable? The other way I was building this initially was to have a field in the data type of tournaments for each of the positions, but this is not scalable given that if I want to expand the tournament to 128 players I would have to add 64 fields more and it’s non-sense. Also in order to find the relationship of the pairs to be able to create the pending match automatically is a mess as I would have to do each pair manually on the backend trigger, which again, is non-sense as it would too many workflows. Thoughts here?
-
Now that I have the players for each position in this positions data type, I just need to pull them to render them. What could be the most efficient wat to pull these? If it’s a 64 player tournament for example, I have a lot of positions to pull. My ideas were:
a) For each position in the chart make a do a search for and search for the specific position and tournament in the positions datatype, but it would be a lot of do a search fors at page load as it would have to look for all positions, so I’m still not sure how performant this is
b) Making a hidden RG and pull there all the available positions of the tournament, and then in each position in the chart just reference it to the RG. At start I tought it could be better, but as I am adding an extra layer of logic I’m not sure, given that it pulls all the info to that RG but step 2 it has to still cascade each of the positions in the search results to each of the positions in the cahrt. I think that if Bubble takes the same time doing all the “do a search fors” for each position then it could be worse to add this layer, but I’m not sure if it would make all the do a searchs fors paralelly given that they’re all pulling the same tournament within the same data type or not.
c) Pushing those positions to a custom state list at page load and then cascading them to each of the positions. I think it’s similar to (b) but worse because if there’s a new position in the positions datatype when I’m in the tournament it will not refresh it except I add another workflow I guess
d) To add also all the positions fields in the tournaments data type as I mentioned in the point 1, but also keep the positions data type, so that when there’s a new position in the positions datatpye it also is added to the position in the tournament data type, so that when Bubble renders players in the tournament chart it just have to look for the field in that tournament data type and not run any search. This sounds better in terms of renderization time, but it’s pretty inefficient in terms of lines of code and fields in the data base (also would be very tiring if I want to expand to more players).
Thoughts?? Appreciate any insight here.
Diego