PHPMem v2.0.1
Version
1.6.45
Uptime
15 days 9 hours 32 minutes 5 seconds
Memory
Total
512MB
Used
24,01MB (4.69%)
Free
487,99MB
Keys
Current
27 650
Total (since start)
33 978
Evictions
0
Reclaimed
160
Expired Unfetched
0
Evicted Unfetched
0
Connections
Current
11 / 1 024 max
Total
170 595
Rejected
0
llm:70074de78535e67276ba18360646203a24bf208868b32c9a18e5ecc2e199d0f2
Edit
# Column classification
This is based on the dataset's column profile (29 profile rows). The profile's own labels are partly wrong, because many numeric columns are stored as text. I've noted where I've corrected it from the column names, and these corrections are my reading of the names, not something I checked in the data.
The profile lists 17 columns each for `raw_kaggle`, `return_kaggle` and `serve_kaggle`, although the card says 21 per table. The other four per table were not in the result, so they are not classified here.
## Identifiers
No single column is a unique ID. Identity comes from composite keys.
- **`players_man_`**: `name` (one row per player).
- **`players_tournament_man_`**: the primary key is `name` + `year` + `tournament`.
- **The three match tables** (`raw_kaggle`, `return_kaggle`, `serve_kaggle`): one row per player per match. The key is `Name` + `Date` + `Tournament` + `Rd`, with `Tournment` as the spelling in `serve_kaggle`.
- `Name` and `Tournament` are the identifier-like columns. The profile marks them as foreign keys in `return_kaggle`.
- `against` (the opponent) is descriptive. It behaves like an identifier, but the profile reports only about 1 distinct value in `return_kaggle`.
## Categorical dimensions
- **`Surface`** (about 4 values) in all three match tables.
- **`Rd`**, the round (about 14 values), in all three match tables.
- **`rounds`** in `players_tournament_man_`.
- **`Tournament` / `Tournment`**, with about 3,963 distinct values. It is high-cardinality, so it is best treated as a grouping label.
- **`Score`**, the match score text, in all three match tables. It is a text label rather than a usable metric.
## Numeric metrics
- **Stored as numbers (DOUBLE or BIGINT):**
- `players_man_.number_of_matches`
- **Rankings:** `Rk` and `vRk` (own and opponent rank) in all three match tables
- **`raw_kaggle` only:** `TP`, `SP`, `1SP`, `2SP`, `Aces`, `DFs` and `vA`
- **Numeric in meaning but stored as text (VARCHAR):**
- **`return_kaggle`:** `TPW`, `RPW`, `vA%`, `v1st%`, `v2nd%`, `DR` and `BPCnv`
- **`serve_kaggle`:** `A%`, `1stIn`, `1st%`, `2nd%`, `Df%`, `Dr` and `Bpsvd`
- The profile labels most of these "classifier" only because they are text. They should be cast before any aggregation. `BPCnv` and `Bpsvd` (break-point conversion and saved) may be fractions rather than plain percentages, so check their format before casting.
## Dates and times
- **`Date` and `Time`** in all three match tables. Both are stored as VARCHAR, so `Date` needs parsing, and the formats look inconsistent, for example "1-Apr-2013" and "9‑Sep‑2024" with a non-standard hyphen.
- **`players_tournament_man_.year`** is a BIGINT, about 2002 to 2024.
- **`players_man_.playing_years`** is a VARCHAR holding a list of years.
## Practical caveats
- Because of the text-typed metrics, don't trust the profile's "measure" vs "classifier" labels without checking the column names.
- The tables share no verified join keys, so `Name` cannot be assumed to join across them.