SQL: Как создать пару версионный ключ: значение, учитывающую неуникальные значения?

Question

Я ищу совет о том, как реализовать версионную пару ключ: val в любом SQL варианте.

(Предположим, сейчас SQlite и Postgres.)

I иметь таблицу, которая предварительно выглядит следующим образом:

locale key version -> value

Локаль и ключ образуют исходный неверсионный кандидат / первичный ключ. Версия добавлена ​​для хранения нескольких версий.

Хитрость в том, что «обновления» в исходных данных (которые я не контролирую) могут увеличить номер версии без изменения значения. В этих случаях я хотел бы подавить изменение номера версии.

Однако я не могу оговорить, что значение является уникальным, потому что я буду sh разрешать переключение значений, например

en_US key1 1 -> "hello world"
en_US key1 42 -> "henlo world"
en_US key1 57 -> "hello world"

- допустимая последовательность: ошибка была случайно введена, а затем откатана. Сохранение данных в том виде, в каком они существовали, около версии 42. Важно.

Однако мы часто можем обнаружить, что версия 58 исходных данных не обновляет значение ключа - так что это «последняя измененная» версия semanti c.

например, следующее является недопустимой последовательностью:

en_US key1 57 -> "hello world"
en_US key1 58 -> "hello world"

Чтобы сохранить семантику "последнего изменения", запись версии 58 не должна была быть добавлена.

Я мог бы выполнить проверку типа «вставить, если» и запросить, соответствует ли последняя версия локали / ключа полученной версии, но я волнуюсь, что это открывает мне условия гонки.

Есть ли более фундаментальный способ смоделировать это ограничение в sqlite / postgres? Я не уверен, что такое ограничение называется формально. (Это не совсем «уникальный».)

Answer 1

Упомянутое вами ограничение является бизнес-правилом. Это пример совершенно логичного требования, которое нельзя аккуратно кодировать в реляционной схеме. Похоже, ваше правило гласит: «Для данной записи, идентифицируемой ключом и локалью, система должна отклонять вставки, если вставленное значение совпадает с последним значением».

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

Итак, я бы реализовал это, как вы внедрите любое другое бизнес-правило, проверив его в логиках приложения c, в своем операторе SQL или с помощью триггера в таблице.