ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подходы к организации версионности сложных документов
25 сообщений из 30, страница 1 из 2
  1  все
Подходы к организации версионности сложных документов
    #35688927
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Всем привет.
Возник вопрос, какие уже существуют подходы по теме, чтобы не изобретать колеса. Есть документ - в общем случае это набор/ы записей во взаимосвязанных и подчиненных таблицах. При внесении изменений как в основную сущность так и в подчиненные необходимо формировать редакцию документа, которая существовала до момента внесения изменений. Один из известных и простых подходов (не сказать умных) - это полное дублирование структуры данных с целью хранить в ней архивные копии сложного документа. Но такой подход обладает недостатками:
Во-первых это избыточность хранимой информации - вынужденность делать полную копию документа при малейших его изменениях.
Во-вторых это сложность разработки и сопровождения впоследствии.
В общем интересуют варианты реализации версионности. Кто создавал свои, кто иcпользовал какие-то известные механизмы - пишите. Обсудим. Спасибо за участие.

P.S. СУБД MS SQL 2005
...
Рейтинг: 0 / 0
02.12.2008, 18:40
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35688963
Зайцев Фёдор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зайцев Фёдор
Участник
delphinchikВо-первых это избыточность хранимой информации - вынужденность делать полную копию документа при малейших его изменениях.
вы хотите иметь доступ к данным, которые не хотите хранить?
...
Рейтинг: 0 / 0
02.12.2008, 19:03
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35688993
sander1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sander1
Участник
Вообще это вопрос не по MS SQL. Если по теме, то иногда удобным является вариант, когда непосредственно изменять документ нельзя, изменения проводятся другими вспомогательными документами, которые в итоге и показывают историю данных.
...
Рейтинг: 0 / 0
02.12.2008, 19:32
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689164
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
Мне кажется, это не так уж сильно отличается от обычной версионности.
Вводится сущность "версия документа", с атрибутами "номер версии"( в простейшем случае возрастающий счетчик) и "дата версии".
Соответственно, есть текущая версия со своим номером.
При изменении, добавлении, удалении элемента(ов) документа создается новая версия с увеличенным номером, предыдущее состояние элементов отходит в историю, в измененные элементы прописывается этот увеличенный номер новой версии.
Таким образом всегда можно получить полное состояние документа для любой версии.
...
Рейтинг: 0 / 0
02.12.2008, 21:38
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689179
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Зайцев ФёдорdelphinchikВо-первых это избыточность хранимой информации - вынужденность делать полную копию документа при малейших его изменениях.
вы хотите иметь доступ к данным, которые не хотите хранить?
Нет, я не хочу делать многократные копии неизменяемых данных в составе документа, у которого изменяется только, к примеру, одно поле.
...
Рейтинг: 0 / 0
02.12.2008, 21:46
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689180
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
Это зависит от того, как вы храните документ. Если у вас используется схема EAV, то там это делается элементарно - записываются только измененные атрибуты. А вот если атрибуты документа - это столбцы таблицы, то уже сложнее...
...
Рейтинг: 0 / 0
02.12.2008, 21:48
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689183
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
sander1Вообще это вопрос не по MS SQL. Если по теме, то иногда удобным является вариант, когда непосредственно изменять документ нельзя, изменения проводятся другими вспомогательными документами, которые в итоге и показывают историю данных.
Возможно. Упоминание о MSSQL я привел из тех соображений, что возможно кто-то знает о существовании стандартных инструментов в составе СУБД, если, конечно, таковые имеются.
Вариант, мне кажется, чересчур сложный для составных документов.
...
Рейтинг: 0 / 0
02.12.2008, 21:49
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689187
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Ennor TiegaelЭто зависит от того, как вы храните документ. Если у вас используется схема EAV, то там это делается элементарно - записываются только измененные атрибуты. А вот если атрибуты документа - это столбцы таблицы, то уже сложнее...
Да, схема классическая. Аттрибуты документа - это столбцы таблицы, или другие, подчиненные документы.
...
Рейтинг: 0 / 0
02.12.2008, 21:50
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689191
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Кот МатроскинМне кажется, это не так уж сильно отличается от обычной версионности.
Вводится сущность "версия документа", с атрибутами "номер версии"( в простейшем случае возрастающий счетчик) и "дата версии".
Соответственно, есть текущая версия со своим номером.
При изменении, добавлении, удалении элемента(ов) документа создается новая версия с увеличенным номером, предыдущее состояние элементов отходит в историю, в измененные элементы прописывается этот увеличенный номер новой версии.
Таким образом всегда можно получить полное состояние документа для любой версии.
Что подразумеваются под "обычной" версионностью? Есть какие то наработанные схемы?
Если я правильно вас понял, то вариант, который вы предлагаете похож на ото, который я описывал в первом своем посте этой темы. За исключением того что как архивные так и текущая версия документа все хранятся в одних и тех же таблицах.
...
Рейтинг: 0 / 0
02.12.2008, 21:54
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689222
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
Если вас так уж напрягает место, занимаемое неизмененными данными, то можете хранить список измененных атрибутов в нетипизированном xml. Правда, это будет приемлемо работать только в том случае, если от вас не потребуют реализовать поиск по истории с фильтрами по этим данным - untyped XML нельзя проиндексировать; кроме того, не все типы данных легко и прозрачно поддаются сохранению в нем.

В принципе, никто не запрещает этот XML типизировать, но тогда у вас будет одна xml schema на один тип документа - мало не покажется, да и редактирование типа документа из относительно простой задачи резко превратится в глючную монстроидальную хрень, в которой черт ногу сломит.

Ну или же пользователям придется уповать на то, что у вас используются не очень длинные маршруты...


Других способов сохранить только часть атрибутов отношения, не нарушая реляционности данных я не знаю. Он и этот-то - не особо правоверный, прямо скажем...
...
Рейтинг: 0 / 0
02.12.2008, 22:16
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689231
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Ennor Tiegael
Других способов сохранить только часть атрибутов отношения, не нарушая реляционности данных я не знаю. Он и этот-то - не особо правоверный, прямо скажем...
Я думаю, что сохраняя только изменения (либо старые версии изменяемых данных - взгляд на проблему с другой стороны), нет необходимости нарушать принципы целостности данных.
...
Рейтинг: 0 / 0
02.12.2008, 22:30
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689257
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Senya_L
Участник
sander1Вообще это вопрос не по MS SQL. Если по теме, то иногда удобным является вариант, когда непосредственно изменять документ нельзя, изменения проводятся другими вспомогательными документами, которые в итоге и показывают историю данных.Честно скажу, прочитал только исходный топик и вот этот, поэтому могу сказать не в тему.

Действительно, вопрос не в тему, особенности MSSQL не затронуты, так что ....
Но по проектированию могу предложить устроить ссылки текущей версии на предыдущую версию. Соответственно у самой первой версии ссылка будет null.
...
Рейтинг: 0 / 0
02.12.2008, 23:10
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689314
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
delphinchikEnnor TiegaelДругих способов сохранить только часть атрибутов отношения, не нарушая реляционности данных я не знаю. Он и этот-то - не особо правоверный, прямо скажем...Я думаю, что сохраняя только изменения (либо старые версии изменяемых данных - взгляд на проблему с другой стороны), нет необходимости нарушать принципы целостности данных.Как вы создадите в таблице половину записи (ну или займете место только под половину столбцов, не суть)? Вы же именно этого хотите:delphinchikНет, я не хочу делать многократные копии неизменяемых данных в составе документа, у которого изменяется только, к примеру, одно поле.Это вам не эксель, тут запись построчная, а не поячеечная. Хотите сохранять только часть кортежа - ломайте реляционную модель, иначе никак.
...
Рейтинг: 0 / 0
03.12.2008, 00:14
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689329
Crimean
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Crimean
Участник
Ennor TiegaelХотите сохранять только часть кортежа - ломайте реляционную модель, иначе никак.

можно нуловые поля делать. определенная экономия места будет
...
Рейтинг: 0 / 0
03.12.2008, 00:28
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689372
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
CrimeanEnnor TiegaelХотите сохранять только часть кортежа - ломайте реляционную модель, иначе никак.можно нуловые поля делать. определенная экономия места будетНавскидку минимум 2 проблемы:
Работает далеко не со всеми типами. Да, собственно, только со строками / блобами и работает.

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

Имхо, весь топик на самом деле не стоит выеденного гроша: вместо того, чтобы добавить несколько дисков в сервер, пытаемся "бегать по заминированному четырехмерному мосту с фонарем на голове и горящей веревкой в руках" (с).
...
Рейтинг: 0 / 0
03.12.2008, 01:39
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689542
SignOff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SignOff
Участник
Топик реально не стоит стольких постов. Автор должен понимать классику - хочешь шустрее - плати (местом, памятью).

Или вот "возможно быстро, качественно, дешево. Выбирай два."

Пока что в этой философии изменений не произошло.

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
03.12.2008, 09:01
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689653
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
2Ennor Tiegael, 2SignOff :
Друзья, ни один из вас не предложил готового решения, а критиковать все мастера. Обратите внимание, что я не делаю упор на экономию памяти, это уже дело десятое. Меня интересуют существующие решения поднятой проблемы : схема данных, логика работы. Ну или хотя бы более менее конкретное словесное описание варианта исходя, например, из собственного опыта. Спасибо.
...
Рейтинг: 0 / 0
03.12.2008, 09:58
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689718
Фотография Ennor Tiegael
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ennor Tiegael
Участник
delphinchikДрузья, ни один из вас не предложил готового решенияМесье топикстартер ослеп ?
delphinchikОбратите внимание, что я не делаю упор на экономию памяти, это уже дело десятое.Правда, что ли? А по тому, как вы делали на этом упор, мне показалось, что для вас это самое важное. Вы уж потрудитесь вербально акцентировать ваши приоритеты в явном виде, чтобы гадать не приходилось.
delphinchikМеня интересуют существующие решения поднятой проблемыТак какой проблемы-то? Экономии места или версионирования сущностей? Если все-таки второе, то большинство так и делает, как вы поначалу не хотели - хранит в базе все данные по каждой версии. Ибо чем более избыточна структура, тем быстрее и проще получаются запросы.
...
Рейтинг: 0 / 0
03.12.2008, 10:20
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35689894
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Ennor TiegaeldelphinchikДрузья, ни один из вас не предложил готового решенияМесье топикстартер ослеп ?
Слишком грубо ). Ваше решение ориентировано на избежание избыточности данных. Спасибо за вариант. Но давайте будем отталкиваться от темы. Избыточность - это следствие решения, она не является решающим фактором.
Ennor TiegaeldelphinchikОбратите внимание, что я не делаю упор на экономию памяти, это уже дело десятое.Правда, что ли? А по тому, как вы делали на этом упор, мне показалось, что для вас это самое важное. Вы уж потрудитесь вербально акцентировать ваши приоритеты в явном виде, чтобы гадать не приходилось.
Хорошо, давайте будем считать, как я уже написал выше, что избыточность не является решающим фактором.
Ennor TiegaelТак какой проблемы-то? Экономии места или версионирования сущностей? Если все-таки второе, то большинство так и делает, как вы поначалу не хотели - хранит в базе все данные по каждой версии. Ибо чем более избыточна структура, тем быстрее и проще получаются запросы.
Проблемы версионирования сущностей.

P.S. И давайте не будем ссориться. Ни к чему это. Если чем то обидел - прошу прощения.
...
Рейтинг: 0 / 0
03.12.2008, 11:04
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690233
Senya_L
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Senya_L
Участник
delphinchik2Ennor Tiegael, 2SignOff :
Друзья, ни один из вас не предложил готового решения, а критиковать все мастера.Эко Вас, батенька, прет Да вобщем-то готовые решения здесь на форуме если и дают, то студентам-второкурсникам по элементарным вопросам. По серьезному делу Вас могут только НАВЕСТИ на решение. Чем вам не вариант, для versioning использовать что-то навроде связанных списков, когда каждая версия содержит указатель на предыдущую версию. Это что-то навроде древовидных структур, но с помощью уникального индекса всегда можно сделать связь "один-ко-одному" и получите такой список. Достаточно стандартное решение. Сам такое не проделывал, но коллеги имели опыт внедрения. Работает нормально.
...
Рейтинг: 0 / 0
03.12.2008, 12:20
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690379
sti
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sti
Участник
delphinchik2Ennor Tiegael, 2SignOff :
Друзья, ни один из вас не предложил готового решения, а критиковать все мастера.

Если потратить немножко усилий на поиск
вот например
...
Рейтинг: 0 / 0
03.12.2008, 13:00
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690383
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Senya_Ldelphinchik2Ennor Tiegael, 2SignOff :
Друзья, ни один из вас не предложил готового решения, а критиковать все мастера.Эко Вас, батенька, прет Да вобщем-то готовые решения здесь на форуме если и дают, то студентам-второкурсникам по элементарным вопросам. По серьезному делу Вас могут только НАВЕСТИ на решение.
Не цепляйтесь к словам :-). Конечно же речь не идет о том чтобы мне здесь обязательно приводили исходники в пример. Речь идет о концепции, которая уже, возможно, была где-то применена.
Senya_L
Чем вам не вариант, для versioning использовать что-то навроде связанных списков, когда каждая версия содержит указатель на предыдущую версию. Это что-то навроде древовидных структур, но с помощью уникального индекса всегда можно сделать связь "один-ко-одному" и получите такой список. Достаточно стандартное решение. Сам такое не проделывал, но коллеги имели опыт внедрения. Работает нормально.
Вполне вариант. Спасибо Вам за информацию. Учту.
...
Рейтинг: 0 / 0
03.12.2008, 13:01
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690391
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
sti, спасибо Вам большое за ссылку. Не читал, но мельком вижу, что труд серъезный и по теме. Спасибо.
...
Рейтинг: 0 / 0
03.12.2008, 13:03
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690630
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
delphinchikКот МатроскинМне кажется, это не так уж сильно отличается от обычной версионности.
Вводится сущность "версия документа", с атрибутами "номер версии"( в простейшем случае возрастающий счетчик) и "дата версии".
Соответственно, есть текущая версия со своим номером.
При изменении, добавлении, удалении элемента(ов) документа создается новая версия с увеличенным номером, предыдущее состояние элементов отходит в историю, в измененные элементы прописывается этот увеличенный номер новой версии.
Таким образом всегда можно получить полное состояние документа для любой версии.
Что подразумеваются под "обычной" версионностью? Есть какие то наработанные схемы?
Если я правильно вас понял, то вариант, который вы предлагаете похож на ото, который я описывал в первом своем посте этой темы. За исключением того что как архивные так и текущая версия документа все хранятся в одних и тех же таблицах.

Вы описывали полное копирование документа в случае изменений, я же предлагаю копировать только изменившиеся элементы. Пример - накладная из 10 позиций, хранится в виде записи-заголовка в одной таблице + 10 записей-позиций в другой. У каждой записи есть некий естественный ключ, первичный ключ таблицы состоит из этого ключа + номер версии. При создании накладной во все записи прописывается номер версии 1.
При добавлении нового элемента текущий номер версии становится 2, В новую позицию накладной прописывается номер версии 2, остальные позиции и заголовок не меняются .
При "сборке" версии 1 документа выбираются элементы с максимальным для каждого значения естественного ключа номером версии, не превышающим требуемый ( то есть 1). итогго туда попадут заголовок + 10 первоначальных элементов (поскольку у них по-прежнему стоит номер 1), а 11 не попадет, поскольку для него нет номера версии, меньшего либо равного 1.
...
Рейтинг: 0 / 0
03.12.2008, 14:09
| Ответить | Цитировать | Написать  
Подходы к организации версионности сложных документов
    #35690682
Фотография delphinchik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
delphinchik
Участник
Кот Матроскин, а если у нас изменилась позиция накладной? Ну например под одной из позиций изменили количество товара. В этом случае вы добавляете новую позицию, которая является копией предыдущей но с измененным количеством товара и новой версией? Я правильно понял?
...
Рейтинг: 0 / 0
03.12.2008, 14:20
| Ответить | Цитировать | Написать  
25 сообщений из 30, страница 1 из 2
  1  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Подходы к организации версионности сложных документов
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=35689179&tid=1543544]:
 0ms
get settings:
 13ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 421ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 65ms
get tp. blocked users:
 1ms
others: 243ms
total:  775ms
созд. / загр.: 775ms
x
x
Закрыть


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