Change Details

The user agent column in the CheckUser result table presents a lot of duplication. This is because user agent strings are often the same between different users and this was made even more of an issue because of {T295073}. As such, having one table to store the user agent strings used by rows in the CheckUser result tables and then referencing these rows by an ID would be a step towards normalising the result tables and would save a non-insignificant amount of space in the database.

The user agent column in the CheckUser result table presents a lot of duplication. This is because, as described in T305930 and T326379, there is a lot of duplication in these columns. This has become even more of a problem since {T295073}. For example, on enwiki there are about on average 200 rows to each distinct user agent string value. Some rough calculations suggest that by de-duplicating the column the `cu_changes` table on enwiki would be several gigabytes smaller. As such, having one table to store the user agent strings used by rows in the CheckUser result tables and then referencing these rows by an ID would be a step towards normalising the result tables and would save a non-insignificant amount of space in the database.

The user agent column in the CheckUser result table presents a lot of duplication. This is because user agent strings are often the same between different users and this was made even more of an issue because of {T295073}, as described in T305930 and T326379, there is a lot of duplication in these columns. This has become even more of a problem since {T295073}. For example, on enwiki there are about on average 200 rows to each distinct user agent string value. Some rough calculations suggest that by de-duplicating the column the `cu_changes` table on enwiki would be several gigabytes smaller. As such, having one table to store the user agent strings used by rows in the CheckUser result tables and then referencing these rows by an ID would be a step towards normalising the result tables and would save a non-insignificant amount of space in the database.