Eliminating Redundant Fields in CMS Versioning to Reduce Cognitive Load

In my CMS, I track versions of site content. The original table looked like this:

CREATE TABLE site_version (
    version_id BIGINT(20) UNSIGNED NOT NULL,
    version_datetime DATETIME(3) NOT NULL,
    version_name VARCHAR(63) NOT NULL,
    description VARCHAR(255) NOT NULL DEFAULT '',
    notes MEDIUMTEXT NOT NULL DEFAULT '',
    PRIMARY KEY (version_id),
    UNIQUE KEY site_version_UN_version_name (version_name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Over time, I noticed that version_name was adding cognitive overhead. I found myself duplicating content between version_name and description, often rewording the same information.

The version_id already serves as the unique identifier (using UTID), and the notes about changes live in description. The name field added no functional value.

To reduce friction, I simplified the schema, inspired by how Git handles commit messages.

Git stores a commit as a unique ID plus a single message. The first line is conventionally treated as "subject", and any subsequent lines as "body". There is no separate short-name field, and empty messages are allowed. This keeps the system simple while maintaining expressiveness.

Applying the same principle, I consolidated version_name and description into a single field. I kept the name description (not message like in Git) for consistency with other tables in my CMS.

I also removed the extra notes field -- any notes go directly into description.

The revised schema is:

CREATE TABLE site_version (
    version_id BIGINT(20) UNSIGNED NOT NULL,
    version_datetime DATETIME(3) NOT NULL,
    description MEDIUMTEXT NOT NULL DEFAULT '',
    PRIMARY KEY (version_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Key points:

  • version_id remains the unique identifier.
  • version_datetime tracks when the version was created.
  • description holds the full message. First line can serve as a subject if needed; the rest can be additional details.
  • description is NOT NULL with a default empty string, mirroring Git’s approach of always having a commit message.

This approach eliminates redundant fields, reduces the cognitive load for contributors, and aligns the workflow with Git’s simple, proven model: unique identifier plus flexible message. Adding versions now requires minimal effort, and the system remains fully queryable for logs and reporting.