Wikimedia Bugzilla is closed!

Currently out logging table has fields log_user, log_namespace, log_title, and log_params, which have to be squeezed to fit all possible things you might want to log, or left blank if irrelevant.  This is not particularly ideal, and results in several issues with loss of data, sorting, and searching.  I would like to deprecate those columns and make a new table, such as: 

CREATE TABLE `logging_params` (
  -- Foreign key to logging table
  `lp_id` int(10) NOT NULL default '',
  -- The type of information being logged.  Specific to the type of log, e.g.,
  -- blocking may have a targetid parameter.  Any given log entry may have 
  -- multiples of these, (lp_id, lp_type) is NOT unique.  This allows things
  -- like multiple protecttype entries for a protection log entry instead of
  -- a single comma-delimited field.
  `lp_type` varbinary(10) NOT NULL default '',
  -- The value of this particular (lp_id, lp_type) pair.  This is NULL just
  -- because some of these fields might be boolean, so may as well use NULL/
  -- NOT NULL as the distinguishing characteristic.
  `lp_value` varchar(255) NULL,
  KEY  (`lp_id`, `lp_type`, `lp_value`)
)

Note: since each log id should correspond to probably two to ten rows in the logging_params table, I'm not sure there's any point in have the key extend to the rather large text fields.