A design of collections for requests and physical check-ins

Get Help Database
1

Hello, community!

Would you suggest a design of collections for requests and check-ins.
In my application, I have two collections:

  • Users;
  • Tournaments.

Collection “Tournaments” contains data about a sport tournaments and have a property “Participants” as a relation to “Users” collection.
Users can apply to a tournament. Users who were applied to the tournament are stored in “Participants” field.

I need make an on-site check-in of applied users.
An organizer of the tournament start it only with the checked-in players. Users/players who was registered as a participant but did not check-in are not take part in the tournament.
During the check-in the organizer can add players who did not send a participation request before.

Thank you for any ideas, suggestions.

2

Hi @Kostas ,

I have made revision here,

It is now called check in/out.

Maybe this can be your reference.

1 Like
3

Hi @Kostas,

I would suggest introducing a 3rd “junction” table (collection) - let’s call it “Participants”.
Fields in the table:

  • Name (not really used, put something to identify the record here)
  • Relationship to Users (one User can have many Participant records, but each Participant belongs to one User)
  • Relationship to Tournaments (one Tournament can have many Participant records, but each Participant belongs to one Tournament)
  • True/False field “Checked In”.

When a user applies to a tournament, the record in Participants collection is created (Logged-in User, current Tournament, Checked In = False).
Upon tournament start, Organiser selects the Tournament and then opens the screen with Participants list (filtered by Current Tournament).

  • If a coming person is in the Participants, Organiser marks this record as “Checked In = True”.
  • If a coming person isn’t in the list, Organiser can add a new record to Participants collection (Logged-in User, current Tournament, Checked In = True).
    After checkin finishes, Organiser can see all the “active” participants by using the “Checked In = True” filter.

Main reason for this: now you’re using many-to-many relationships, which are not the best for larger collections. Also, now you won’t be able to store additional info about participation (for example, checkin, or date of application, or price paid, or something else).

Hope this helps.

Best regards, Victor.

1 Like
4

Hi guys!

Thank you all for answering.
@Victor, you are precisely caught my question. Will do so.
Would you please give a clue to which relations, except many-to-many more convenient. A player would have many tournaments and tournaments would have many players.

5

Hi @Kostas,

Not sure that I understood your question :slight_smile: M2M relationships could be replaced by junction tables - which I’ve described. The reason to avoid M2M is speed - it takes more time for this relationships to be “processed” in Adalo apps, which leads to bad user experience due to delays in visualisation.

Best regards, Victor.

2 Likes