Не сочтите за рекламу, просто делюсь своим опытом.
Версионность справочников и реестров
авторВ статье приведен новый легкий алгоритм для организации версионности справочников. Возможно, это все было придумано до меня, но в открытых источниках мне не удалось найти описание этого подхода.
Описанный алгоритм используется нами на реальном проекте.

guest_20040621,

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

scf,

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

NafА зачем это? Обычно изменяются лишь некоторые параметры, причем они зависят зачастую не только от справочника
Шаблон: Периодические сведения
В нашем случае изменялись сразу несколько справочников, причем за несколько транзакций:
- ночью из внешней системы подкачивается справочник на 10 тысяч записей (XML), он автоматом сравнивается с имеющимися данными, если есть изменения - обновляется одна из таблиц в базе;
- утром оператор жмет кнопку "обновить тарифы", и в другом справочнике из миллиона значений меняется пара тысяч записей;
- в течении недели тетечка проверяет, все ли верно обновилось, иногда вносят правки ручками в отдельные записи;
- потом это все безобразие одобряется третьим лицом и справочники можно распространять.
И на распространение ни в коем случае не должны попадать промежуточные правки.
В этих условиях Периодические сведения (оно же Log trigger) не подходят.

Naf,

потому что "Log trigger" в качестве "новой версии" использует текущее время (на момент редактирования).
Это хорошо для хранения истории изменений в одной таблице. Но когда изменения вносятся сразу в несколько таблиц, то хочется чтобы версия "тикнула" один раз для всех изменений. Если у вас все таблицы изменяются за одну транзакцию, то "Log trigger" все еще подходит, можно на начала транзакции взять текущее время и везде его проставить.
У нас транзакций было много, значит это время надо где-то отдельно запоминать.
А еще хотелось чтобы изменения для клиентов вступали в силу не сразу, а через неделю, значит прописывать надо не время редактирования, а особое время действия.
Вот и появилась таблица с номерами версий и метаданными для каждой версии (статусы, каменты и т.д.), для удобства сами номера версий заменили на целые числа вместо времени.
Это очень похоже на шаблон "Log trigger", но уже не совсем он.

Naf,

а теперь представьте, что надо эти справочники выгрузить наружу, заблаговременно, диффом. Что спросит клиент? "Дай мне справочник на 01.01.2015"?
А спрашивать ли ему после этого "справочник за 01.12.2014"? Ведь вы можете добавить такую строчку в будущем.

пгуые123,

давайте конкретнее, где описан подходящий алгоритм среди тех 500+ страниц? А может быть нигде?

USDS мы здесь обсуждать не будем, не профильная ветка форму.

Wizandr,

в статье это все как раз описано :)

Ксения Разработчик,

мне кажется, это гиблое дело.
Лучше при смене структуры мигрировать все данные на новую схему. Даже старые версии справочников спокойно мигрируются.
Можно попытаться хранить справочники в не реляционной БД, например: одна версия справочника - один JSON-документ в MongoDB. Но это еще более гиблое дело :)