Добрый день!

Вопрос, который при всей тривиальности поставил в тупик.
Задача: есть таблица. с определенным Unique Key.
Необходимо контролировать версионность записей в данной таблице.
(т.е. изменения/добавления/удаления) сохранять в архиве.

И маленькое, но главное, условие - каждое изменение записи инкрементит версию записи на 1.

Вопрос - как организовать данный инкремент?
Понятно, что тривиальные путь - выбрать максимальную версию из архива = сделать + 1.
Либо хранить в самой записи ее текущую версию и инкрементить на 1.

НО! Может быть есть какие-то более изящные решения?
Может быть есть СУБД, в которых реализован sub-identity (т.е. инкрементность в пределах уникального ключа?)

SERG1257Теперь вы хотите чтобы например для записи с id = 123 ver_id были 1,2,3,4 ... Так?
А почему не сделать ver_id identity? Пускай будет уникальным не в пределах id, а в пределах таблицы?
Mikle83 И маленькое, но главное, условие - каждое изменение записи инкрементит версию записи на 1. Небось еще и без дырок?

Может быть не совсем верный подход с точки зрения БД, но хранение версий облегчает жизнь пользователям: появляется возможность оперировать понятием "3-я версия документа"/"внесены изменения в 8 версию и т.д.".

При этом пользователи привыкают, что действительно инкремент непрерывный и ожидают увидеть после пятой - шестую версию.
И понимать, как изменялся документ от версии к версии (видя всю историю). И при этом версии никак не могут поменяться - они "жестко" привязаны к конкретной иттерации.

Можно, конечно же подобный функционал вынести на клиента, но уже с жесткой привязкой проблемы.

Кот МатроскинSERG1257,
ТС, как понимаю, как раз хочет чтобы восьмая версия оставалась восьмой независимо от того, существует ли еще седьмая или нет.


Да, именно так, поэтому и отписал в посте №3 - что нумерование на стороне клиента не совсем устраивает.


АнатоЛойMikle83, поле с номером версии добавляете как в основную таблицу, так и в таблицу версий. У таблицы версий свой уникальный ключ. У таблицы версий альтернативный ключ на 2 поля: ключ основной таблицы и номер версии. Последовательность действий при сохранении новой версии:
1. Добавляем запись в таблицу версий. Получаем current_ver_id
2. Обновляем номер версии в добавленной записи как count(*)+1 where ver_id < current_ver_id and id=current_id
3. Обновляем номер версии в основной таблице

Это-то понятно, так и сделано сейчас (см первый пост в теме), но было желание осмотреться по СУБД = может есть в каких-то штатные средства, т.к. в ручную "прорисовывать" для каждой таблицы такое обновление - не айс,
а "городить" универсальный сабидентити - оно конечно же можно (и, в принципе, к этому сейчас и пришел), но ИМХО странно, что СУБД не дают готового интерфейса.

АнатоЛойТвой Sub-identity есть функция от данных (значений в записях таблицы) и предыдущего вызова функции для этой же записи.
Как ты себе это представляешь в виде реализации "из ядра"?

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