|
|
|
Подходы к организации версионности сложных документов
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинdelphinchikКот МатроскинМне кажется, это не так уж сильно отличается от обычной версионности. Вводится сущность "версия документа", с атрибутами "номер версии"( в простейшем случае возрастающий счетчик) и "дата версии". Соответственно, есть текущая версия со своим номером. При изменении, добавлении, удалении элемента(ов) документа создается новая версия с увеличенным номером, предыдущее состояние элементов отходит в историю, в измененные элементы прописывается этот увеличенный номер новой версии. Таким образом всегда можно получить полное состояние документа для любой версии. Что подразумеваются под "обычной" версионностью? Есть какие то наработанные схемы? Если я правильно вас понял, то вариант, который вы предлагаете похож на ото, который я описывал в первом своем посте этой темы. За исключением того что как архивные так и текущая версия документа все хранятся в одних и тех же таблицах. Вы описывали полное копирование документа в случае изменений, я же предлагаю копировать только изменившиеся элементы. Пример - накладная из 10 позиций, хранится в виде записи-заголовка в одной таблице + 10 записей-позиций в другой. У каждой записи есть некий естественный ключ, первичный ключ таблицы состоит из этого ключа + номер версии. При создании накладной во все записи прописывается номер версии 1. При добавлении нового элемента текущий номер версии становится 2, В новую позицию накладной прописывается номер версии 2, остальные позиции и заголовок не меняются . При "сборке" версии 1 документа выбираются элементы с максимальным для каждого значения естественного ключа номером версии, не превышающим требуемый ( то есть 1). итогго туда попадут заголовок + 10 первоначальных элементов (поскольку у них по-прежнему стоит номер 1), а 11 не попадет, поскольку для него нет номера версии, меньшего либо равного 1.Со списками все понятно, это действительно довольно очевидное решение. Другой вопрос, когда документ состоит из одной записи в одной таблице, в нем 50 пользовательских атрибутов, и на какой-то стадии меняется только один из них. Я так понял, что автора интересовал именно этот случай. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2008, 14:21 |
|
||
|
Подходы к организации версионности сложных документов
|
|||
|---|---|---|---|
|
#18+
delphinchik, да, именно так. Ennor Tiegael, мне кажется, что если нужна версионность отдельных атрибутов и при этом критичен обьем данных, то хранить 50 атрибутов в одной таблице всяко не лучшее решение. Как уже выше говорили, либо полностью переходить на EAV, либо оставить запись с 50 атрибутами для актуальных данных, и хранить в виде EAV только историю атрибутов - имхо так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2008, 14:46 |
|
||
|
Подходы к организации версионности сложных документов
|
|||
|---|---|---|---|
|
#18+
Ennor Tiegael, да и этот случай тоже. И документ может состоять не "из одной записи в одной таблице", а в общем случае из набора записей в наборе таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2008, 14:47 |
|
||
|
Подходы к организации версионности сложных документов
|
|||
|---|---|---|---|
|
#18+
[quot Кот Матроскин]delphinchik, да, именно так.quot] Спасибо за вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2008, 14:49 |
|
||
|
Подходы к организации версионности сложных документов
|
|||
|---|---|---|---|
|
#18+
В каждой записи документа определить два атрибута - версия документа с которой начинается действие редакции и версия документа, после которой запись была удалена из документа. В простом случае это могут быть две даты - дата добавления записи в документ и дата исключения записи из документа (по умолчанию это дата в далёком будущем). В более сложном случае, нужно завести таблицу редакций документа с монотонной нумерацией записей и вместо дат использовать номера редакций. Чтобы собрать нужную редакцию документа нужно будет сделать запрос типа: Код: plaintext Кроме случаев исправления ошибок ввода данных записи документа никогда не удаляются и не изменяются (кроме поля last_issue, которое изменяется при логическом удалении записи из новой редакции документа). Статус редакции документа определяет возможность изменять её записи. Ограничения ссылочной целостности становятся неприменимы. Первичные ключи и unique тоже теряют смысл. Остаётся вопрос, как должны влиять исправления в ранних редакциях документа на более поздние редакции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2008, 19:31 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1543544]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
186ms |
get topic data: |
12ms |
get first new msg: |
6ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 201ms |
| total: | 499ms |

| 0 / 0 |
