Замена слишком большого составного ключа

Question

Я пытаюсь найти лучшее решение для данной проблемы:

У меня есть объект (назовем его Collateral), который состоит из нескольких полей.Уникальность этой сущности определяется составом из 4 полей (назовем их: user_id (bigint), device_id(varcha(9)), key_id(varchar(2732)), application_id(varchar(255)))

Эта таблица генерируется в режиме гибернации.Я пытался как переместить эти 4 поля в отдельный объект (CollateralEmbeddedEntity), чтобы использовать его в качестве встроенного идентификатора, и создать ограничение для этих 4 полей в Collateral Entity:

@Table(
    name="COLLATERAL",
    uniqueConstraints=
    @UniqueConstraint(name = "comp_key", columnNames={"device_id", "application_id", "key_id", "user_id"}))

Проблема заключается в том, чтов обоих случаях поля в целом превышают максимально допустимую длину ключа MariaDB:

java.sql.SQLException: Specified key was too long; max key length is 3072 bytes

Изменение кодировки (сопоставление) dbCharset или сжатие самого диапазона полей varchar недопустимо.

Я подумал о том, чтобы сгенерировать и сохранить хэш этих 4 полей и наделить его уникальным ограничением (в любом случае поиск и обновление всегда будут основаны на этих 4 полях), но я не уверен, что такое решениеэто уместно, поскольку мы нарушаем нормализацию базы данных излишней информацией.

Является ли решение с хешем на самом деле хорошим?Если нет, каковы лучшие альтернативы для данной проблемы?

Answer 1

Нормализовать ключ сертификата:

CREATE TABLE CertKeys (
    cert_id INT UNSIGNED AUTO_INCREMENT,
    cert_key VARCHAR(2732) NOT NULL,   -- base64 encoded
    -- or:  cert_key VARBINARY(2049) NOT NULL,   -- binary
    PRIMARY KEY (cert_id),
    UNIQUEY (cert_key) ) ENGINE=InnoDB;

Затем используйте cert_id в другой таблице и в составной таблице INDEX, о которой вы говорите.

Требуется дополнительный шаг длявставьте ключ cert_key в новую таблицу и получите cert_id.Это делается перед вставкой в ​​основную таблицу.

Это менее критично, но вы также можете подумать о нормализации application_id.

(Да, можно использовать другую технику, используя хеш, ноЯ думаю, что это чище.)