powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подходы к организации версионности сложных документов
5 сообщений из 30, страница 2 из 2
Подходы к организации версионности сложных документов
    #35690686
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинdelphinchikКот МатроскинМне кажется, это не так уж сильно отличается от обычной версионности.
Вводится сущность "версия документа", с атрибутами "номер версии"( в простейшем случае возрастающий счетчик) и "дата версии".
Соответственно, есть текущая версия со своим номером.
При изменении, добавлении, удалении элемента(ов) документа создается новая версия с увеличенным номером, предыдущее состояние элементов отходит в историю, в измененные элементы прописывается этот увеличенный номер новой версии.
Таким образом всегда можно получить полное состояние документа для любой версии.

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

Вы описывали полное копирование документа в случае изменений, я же предлагаю копировать только изменившиеся элементы. Пример - накладная из 10 позиций, хранится в виде записи-заголовка в одной таблице + 10 записей-позиций в другой. У каждой записи есть некий естественный ключ, первичный ключ таблицы состоит из этого ключа + номер версии. При создании накладной во все записи прописывается номер версии 1.
При добавлении нового элемента текущий номер версии становится 2, В новую позицию накладной прописывается номер версии 2, остальные позиции и заголовок не меняются .
При "сборке" версии 1 документа выбираются элементы с максимальным для каждого значения естественного ключа номером версии, не превышающим требуемый ( то есть 1). итогго туда попадут заголовок + 10 первоначальных элементов (поскольку у них по-прежнему стоит номер 1), а 11 не попадет, поскольку для него нет номера версии, меньшего либо равного 1.Со списками все понятно, это действительно довольно очевидное решение. Другой вопрос, когда документ состоит из одной записи в одной таблице, в нем 50 пользовательских атрибутов, и на какой-то стадии меняется только один из них.
Я так понял, что автора интересовал именно этот случай.
...
Рейтинг: 0 / 0
Подходы к организации версионности сложных документов
    #35690806
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
delphinchik, да, именно так.

Ennor Tiegael, мне кажется, что если нужна версионность отдельных атрибутов и при этом критичен обьем данных, то хранить 50 атрибутов в одной таблице всяко не лучшее решение. Как уже выше говорили, либо полностью переходить на EAV, либо оставить запись с 50 атрибутами для актуальных данных, и хранить в виде EAV только историю атрибутов - имхо так.
...
Рейтинг: 0 / 0
Подходы к организации версионности сложных документов
    #35690811
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ennor Tiegael, да и этот случай тоже. И документ может состоять не "из одной записи в одной таблице", а в общем случае из набора записей в наборе таблиц.
...
Рейтинг: 0 / 0
Подходы к организации версионности сложных документов
    #35690817
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot Кот Матроскин]delphinchik, да, именно так.quot]
Спасибо за вариант.
...
Рейтинг: 0 / 0
Подходы к организации версионности сложных документов
    #35691770
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В каждой записи документа определить два атрибута - версия документа с которой начинается действие редакции и версия документа, после которой запись была удалена из документа.

В простом случае это могут быть две даты - дата добавления записи в документ и дата исключения записи из документа (по умолчанию это дата в далёком будущем). В более сложном случае, нужно завести таблицу редакций документа с монотонной нумерацией записей и вместо дат использовать номера редакций.

Чтобы собрать нужную редакцию документа нужно будет сделать запрос типа:

Код: plaintext
select .... where .... :issue between first_issue and last_issue ...

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

Статус редакции документа определяет возможность изменять её записи.

Ограничения ссылочной целостности становятся неприменимы. Первичные ключи и unique тоже теряют смысл.

Остаётся вопрос, как должны влиять исправления в ранних редакциях документа на более поздние редакции?
...
Рейтинг: 0 / 0
5 сообщений из 30, страница 2 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подходы к организации версионности сложных документов
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]