By Onkar Jadhav · 8 min read
Running a player database that survives three seasons.
The organizer’s side of player records: how duplicates get in, how to categorise a pool for an auction, how to track availability, and what to do when a player changes team.
How do you run a cricket player database?
Managing a cricket player database comes down to one rule applied consistently: every player has exactly one record, keyed on mobile number, and team membership is a link from that record to a squad rather than a field on it. Storing the team on the player record is what makes a player’s history disappear the moment they change sides.
One rule, applied without exception
Every player has exactly one record, keyed on mobile number, and team membership is a link from that record to a squad rather than a field on it.
That is the whole discipline, and getting it wrong is the reason most local cricket databases are useless by their third season. Storing the team as a field on the player means changing it erases the connection to everything they did for the previous side: their statistics, their auction price, their appearances. Modelled as a link, the player accumulates a second squad entry and keeps all of it.
How duplicates get in
Three routes, and all three are caught by a uniqueness check on mobile number at the point of entry.
- The player registers twice. Usually because they were not sure the first submission worked.
- A bulk import is merged with an open form. The same player arrives through both routes with two spellings of their name.
- A returning player is entered by hand. The organizer did not find the existing record, often because they searched the name the player used last season.
Name-matching produces both false duplicates, because two players genuinely share a name, and missed real ones, because the same player spells their own name differently. Number-matching has neither problem. Registration field design.
Categorising a pool for an auction
After registration closes and before the lot order is generated, because the tier determines which set a player appears in and therefore when in the auction they come up.
| Tier | Size | Base price | Purpose |
|---|---|---|---|
| Marquee | 4 to 8 players | 3 to 5× floor | Opened first while every purse is full |
| Tier one | 15 to 25% | 2 to 3× floor | Where the real spending happens |
| Tier two | 25 to 35% | 1 to 2× floor | Squad players with a known standard |
| General pool | The rest | Floor | Fills out squads at the end |
Base prices from last season’s actual sale prices beat an organizer’s impression of who is good, which is the main practical argument for keeping auction history at all.
Availability belongs on the match
Track availability as a per-match flag, not a profile field. Availability is specific to a date, and a profile flag set once stays set for the whole season by accident, which means the organizer stops trusting it and goes back to WhatsApp.
A player marked unavailable for round three is giving you information you can act on. A player marked unavailable in general is giving you nothing.
What survives three seasons
If the one rule at the top holds, a three-season database gives you four things that are genuinely hard to get any other way: each player’s full appearance record, their aggregate figures, their auction price trend, and a base-price tier structure grounded in what teams actually paid.
That is the point at which a recurring tournament starts to feel like a league with a history rather than an annual event. What else changes across seasons.
Player management FAQ
How do duplicate player records get created?
Three ways: the player registers twice for the same tournament, a bulk import is merged with an open registration form, and a returning player is entered by hand because the organizer did not find their existing record. All three are caught by a uniqueness check on mobile number at the point of entry.
How should a player pool be categorised for an auction?
Into three or four base-price tiers on playing standard, with the tier definitions published. Categorise after registration closes and before the lot order is generated, because the tier determines which set a player appears in and therefore when in the auction they come up.
How do you track availability?
As a per-match flag rather than a profile field, because availability is specific to a date. A player marked unavailable on their profile stays unavailable for the whole season by accident; a player marked unavailable for round three is giving you the information you actually need.
What happens to a player’s record when they change team?
Nothing, if team membership is modelled as a link from squad to player. The player keeps one record and accumulates a second squad entry, so their statistics and auction history stay whole. If the team is a field on the player row, changing it erases the connection to everything they did for the previous side.