ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / полная декомпозиция для истории изменений
25 сообщений из 58, страница 1 из 3
  1  все
полная декомпозиция для истории изменений
    #34041657
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Тема хранения истории изменений неоднократно обсуждалась, однако некоторые решения все же не были особо затронуты.
Итак, как вы относитесь к полной декомпозиции для хранения истории?
Имеется довольно разветвленный объект для которого требуется хранить историю изменения каждого атрибута.
Если атрибутов много и иерархия объекта вцелом очень большая, то решение на таблице-дубликате для истории окажется слишком расточительным и тяжелым если у объекта в какой то момент времени меняется только один атрибут.
Если история должна быть 2-х уровневой, то расточительность еще большая если меняется только 1 атрибут из 100 (допустим).
Решение видится в том, чтобы для истории(только для истории) полностью декомпозировать первичные сущности и выделить на каждый атрибут по отдельной таблице.
Имел ли кто-нибудь опыт с подобным решением, пожалел ли или наоборот доволен?
Какие трудности возникали, с чем пришлось побороться?

p/s/
Все остальные способы мне хорошо известны и в форуме достаточно освящены, как то:
-таблица-дубликат (без декомпозиции)
-история в той же таблице
-история в виде структуры объект-атрибут-значение
-...прочие вариации на тему предыдущих
большая просьба в этой ветке их не затрагивать и не обсуждать.
задача/предметная область - зарплатный софт, учетные системы .
...
Рейтинг: 0 / 0
09.10.2006, 14:08
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041735
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
При условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида

Код: plaintext
1.
2.
3.
table_id  integer
rec_id    integer
old_value integer [float, varchar, по желанию, либо несколько полей разных типов]

На каждую таблицу с данными навешиваем триггер, который добавляет запись в таблицу истории LOG.
Поле table_id идентифицирует таблицу, в которой изменилась запись с ключом rec_id. Прежнее значение видим в поле old_value.
Как-нибудь особо отмещать факт удаления записи. В случае ЗП, лучше не удалять, а помечать для удаления и не применять в расчетах, но хранить в БД.

Т.о. нет избыточности, но можно проследить всю последовательность изменения каждой записи.

С уважением.

PS. Вроде бы это не попадает в "остальные способы", которые вы просили не обсуждать, надеюсь не нафлудил.
...
Рейтинг: 0 / 0
09.10.2006, 14:28
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041823
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида

Код: plaintext
1.
2.
3.
table_id  integer
rec_id    integer
old_value integer [float, varchar, по желанию, либо несколько полей разных типов]

ИМХО:
- недостает идентификатора измененного атрибута.
- с учетом этого факта связывать изменения атрибутов с оригинальной записью средствами SQL будет довольно непросто.
...
Рейтинг: 0 / 0
09.10.2006, 14:49
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041837
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторИМХО:
- недостает идентификатора измененного атрибута.
Совершенно верно.
Так давайте же его добавим. Определять его значение будем триггере на изменение записи.
Заодно добавим поля для хранения времени и пользователя, выполневшегоо изменения. Ну и IP можно подтянуть при желании :)
...
Рейтинг: 0 / 0
09.10.2006, 14:54
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041880
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман ДынникРешение видится в том, чтобы для истории(только для истории) полностью декомпозировать первичные сущности и выделить на каждый атрибут по отдельной таблице.


Так понял, на каждое значение поля "атрибут" создаём отдельную таблицу, тогда в таблице для определённого атрибута достаточно хранить пару "объект-значение".
Принципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю, а особенности работы с такой структурой следует обсуждать в форуме по конкретной СУБД. Скорее всего будут предложены системные способы протоколирования изменений, так что желание изобретать велосипед отпадёт само собой.

Видимо, следует оптимизировать структуру БД и логику приложения, чтобы большие объекты изменялись как можно реже.
...
Рейтинг: 0 / 0
09.10.2006, 15:03
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041925
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю
Действительно :)

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

К сожалению обозначенная предметная область "зарплатный софт" исключает измеение "как можно реже". Ежемесячно вносится и правится большое количество записей. И за каждой из них стоит очень конкретный рубль.

С уважением.
...
Рейтинг: 0 / 0
09.10.2006, 15:16
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041969
Фотография AnS1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AnS1
Участник
в R/3 сделано так
1 есть таблица
- вид объекта
- код объекта
- имя поля (можно это и структурировать)
- значение до
- значение после
- автор изменения
- дата \ время изменения

объяснять атрибуты не нужно, думаю

2 имеется простое api - записать изменение \ считать изменение для объекта и проч. Никто не запрещает использовать и select
3 контроль изменений настраивается в каждой функциональности отдельно. По умолчанию - прописано везде. Для новых разработок надо встраивать - создать новый вид объекта, встроить вызовы api

На данный момент в рабочей системе 12 млн. записей, проблем с производительностью нет.
...
Рейтинг: 0 / 0
09.10.2006, 15:31
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041973
Фотография AnS1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AnS1
Участник
AnS1

На данный момент в рабочей системе 12 млн. записей, проблем с производительностью нет.
имеется ввиду таблица с историей :)
...
Рейтинг: 0 / 0
09.10.2006, 15:32
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34041987
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю
в данном случае имелся ввиду вариант, когда существуют 3 таблицы на все типы, т.е. таблица значений - {ObjectID, AttributeID,DTBegin,DTEnd, Value varchar(255)}, что во многих случает не есть гуд.

Я же имел ввиду вариант больше похожий на таблицу-дубликат, но полностью декомпозированную, т.е. для каждого исторического атрибута - таблица (ObjectID,DTBegin, DTEnd,Value [того типа который и используется, а не variant или varchar на все случае жизни]). Атрибут соответственно определяет таблица (т.е. никаких AttributeID!). Отличия, имхо, значительные! Структура более реляционная...
...
Рейтинг: 0 / 0
09.10.2006, 15:37
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042001
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
AnS1в R/3 сделано так
1 есть таблица
- вид объекта
- код объекта
- имя поля (можно это и структурировать)
- значение до
- значение после
- автор изменения
- дата \ время изменения

это вариант объект-атрибут-значение!
...
Рейтинг: 0 / 0
09.10.2006, 15:39
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042026
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида
История соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике.
...
Рейтинг: 0 / 0
09.10.2006, 15:45
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042056
Фотография AnS1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AnS1
Участник
Роман Дынник CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида
История соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике.
есть впечатление, что пытаемся все многообразие бизнес-логики впихнуть в метаданные (метатаблицу). Что-то похожее уже делали и не раз для документов, для процессов. Честно говоря, ничего хорошего так и не получили.
Берем процесс, смотрим, для каких целей используются в нем исторические значения, проектируем структуру данных, ориентированную на процесс. ИМХО, эффективно и производительно :)
...
Рейтинг: 0 / 0
09.10.2006, 15:51
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042221
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман Дынник авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю
в данном случае имелся ввиду вариант, когда существуют 3 таблицы на все типы, т.е. таблица значений - {ObjectID, AttributeID,DTBegin,DTEnd, Value varchar(255)}, что во многих случает не есть гуд.

Я же имел ввиду вариант больше похожий на таблицу-дубликат, но полностью декомпозированную, т.е. для каждого исторического атрибута - таблица (ObjectID,DTBegin, DTEnd,Value [того типа который и используется, а не variant или varchar на все случае жизни]). Атрибут соответственно определяет таблица (т.е. никаких AttributeID!). Отличия, имхо, значительные! Структура более реляционная...

Концептуально отличий нет. Это только вопрос реализации и результат его исследования сильно зависит от конкретной СУБД.
В Оракле таблицу (объект, атрибут, значение) можно секционировать, использовать сжатие индекса, в итоге горизонтальная декомпозиция такой таблицы пойдёт скорее во вред чем на пользу. Это правило будет справедливым для большинства РСУБД, поскольку их разработчики в большей спенени ориетнируются на нормализованные данные (число отношений минимально), чем на декомпозированные до потери смысла.

Некоторым компромиссом можно назвать многомерные базы данных. Применительно к задаче журналирования, в них значения атрибутов (или их устойчивых групп) остаются неизменными (таблицы со значениями атрибутов называются измерениями), а исторические изменения связи объекта со значениями атрибутов регистрируются в таблице фактов.
Возможно, это твой случай.
...
Рейтинг: 0 / 0
09.10.2006, 16:34
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042294
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторИстория соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике.

Позволю предположить, что от этого можно уйти. Это неэффективный подход к делу.

С уважением.
...
Рейтинг: 0 / 0
09.10.2006, 16:52
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042503
Фотография Garya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GaryaПривилегированный пользователь
Участник
Я пытался решать эту задачу (а попутно еще и несколько других). Посмотрите презенатцию , там кое-что есть на эту тему. Я допустил ошибку в структуре данных для хранения древовидных путей (поместил пути целиком в warbinary) - из-за этого поиск поддерева в дереве потребовал FullScan. Я знаю, каким образом изменить структуру данных, чтобы решить конкретно эту проблему (правда, придется переписывать 30% текстов триггеров и хранимых процедур и примерно столько же кода клиентской части). Но там есть еще одна проблема, решения которой я пока не нашел. Это проблема быстродействия на операциях записи.

Вся основная информация, фактически, хранится в 6 таблицах. Новые структуры данных не приводят к увеличению числа таблиц, просто появляется еще одно описание метаданных и несколько автоматически генеримых триггерами (на таблице, в которой описываются метаданные) VIEW опять же с автоматически генеримыми текстами instead-триггеров. В главной таблице хранится только мимнимальная системная информация о всех объектах ВООБЩЕ (что-то вроде указателя на любой объект, приведенный к дельфишному типу TObject). Все атрибуты объектов располагаются в другой таблице (в полях типа sql_variant - чтобы можно было хранить данные разных типов), сборка объектов в единое целое производится вьюхами. Главная проблема - это конкурирующая запись в такие структуры при большом числе пользователей. Происходят блокировки индекса, всё страшно тормозит.
Идеи просто шикарные (там кроме журнализации решается еще вопрос версионности, вынос конфликтов репликации на уровень бизнес-логики, прямоуголных проекций на иерархические структуры данных, преемственности модифицируемых алгоритмов обработки данных и многого другого), но вот с быстродействием - полная труба... :(
Так что... Чапай думает дальше... :) Может быть когда-нибудь что-нибудь и придумаю.

А вообще, я убежден, что сегодня назрела реальная необходимость включения подобных механизмов в состав самих СУБД. В принципе, тот же MS SQL имеет журнал транзакций, в котором сохраняется история изменения записей. Требуется всего-навсего предоставить расширение языка T-SQL, с помощью которого SQL Server смог бы производить выборку из своего собственного лога информации о модификации записей. Я полагаю, что при желании вендоры СУБД могли бы это сделать. В предложениях клуба RSUG в адрес MS было включено подобное предложение. MS обещал над ним подумать... :)
...
Рейтинг: 0 / 0
09.10.2006, 17:39
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042583
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
GaryaТребуется всего-навсего предоставить расширение языка T-SQL, с помощью которого SQL Server смог бы производить выборку из своего собственного лога информации о модификации записей. Я полагаю, что при желании вендоры СУБД могли бы это сделать. В предложениях клуба RSUG в адрес MS было включено подобное предложение. MS обещал над ним подумать... :)

В Оракле эта функция называется flashback query. Т.е. запрос состояния БД на момент времени в прошлом. Вот только глубина такого просмотра ограничена. Да и копание в журнале процесс довольно медленный. Так что лучше исторические данные хранить в виде отношений БД, оптимизированных для решения конкретных задач, а навороты использовать к месту, в долгоиграющих отчётах, при восстановлении данных после ошибок пользователя.
...
Рейтинг: 0 / 0
09.10.2006, 18:03
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042673
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
mcureenabВ Оракле таблицу (объект, атрибут, значение) можно секционировать, использовать сжатие индекса, в итоге горизонтальная декомпозиция такой таблицы пойдёт скорее во вред чем на пользу. Это правило будет справедливым для большинства РСУБД, поскольку их разработчики в большей спенени ориетнируются на нормализованные данные (число отношений минимально), чем на декомпозированные до потери смысла.
Люди, вариант объект-атрибут-значение это не реляционная структура!
То что сервера нам дают возможность решать проблемы с производительностью посредством секционирования и прочего не решает множества мелких и не очень проблем при подобном подходе.
Такая структура хорошо подходит и имеет право на жизнь когда невозможно на этапе проектирования определить количество атрибутов у объекта и количество типов этих объектов, их иерархию наследования (товары с их свойствами, например).
...
Рейтинг: 0 / 0
09.10.2006, 18:31
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042699
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
2 Garya
Да, я смотрел внимательно презентацию пару лет назад, в свое время очень помогло на одном из проектов. Много хороших идей, про оси времени, про группы свойств и расширяемость и т. д.
Но все же, имхо, объект-атрибут-значение - это для гибкости и расширяемости. Когда же на этапе проектирования все известно не стоит все унифицировать до 3-х таблиц.
...
Рейтинг: 0 / 0
09.10.2006, 18:38
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042702
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm авторИстория соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике.
Позволю предположить, что от этого можно уйти. Это неэффективный подход к делу.
С уважением.
В том то и вопрос, как эффективней и правильней.
...
Рейтинг: 0 / 0
09.10.2006, 18:40
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042851
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман ДынникЛюди, вариант объект-атрибут-значение это не реляционная структура!

Ничего подобного. Это тоже реляционное отношение, но отражающее элементарные функциональные зависимости в предельном случае. То что мы здесь обсуждаем вопрос чисто теоретический. Автор довёл структуру до предельного уровня декомпозиции. Соединяя кортежи мы сможем получить исходные отношения. Т.е. с реляционной точки зрения почти всё Ок, никаких формальных противопоказаний к использованию подхода автора нет, разве что количество отношений скорее всего гораздо больше чем это нужно для устранения всех аномалий. Прочие доводы скорее всего будут явно или не явно связаны с особенностями реализации, которые здесь обсуждать нет смысла.

Автору я бы посоветовал получше сформулировать конкретную задачу, сократить количество отношений до необходимомо минимума и определиться с СУБД, на которой он будет её решать, а не бросаться в крайности.
...
Рейтинг: 0 / 0
09.10.2006, 20:23
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34042863
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман ДынникВ том то и вопрос, как эффективней и правильней.

К БД в отрыве от решаемых задач невозможно применять эти категории.
Сформулируй задачи, которые нужно решить с помощью БД, рассмотри варианты БД, и оцени с каким из них задачи решаются правильно и достаточно эффективно. Скорее всего, истина будет не далеко от нормализованной БД, где невозможны определённые классы аномалий изменения при минимальном количестве реляционных отношений.
...
Рейтинг: 0 / 0
09.10.2006, 20:32
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043293
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
задача впринципе обозначена была в первом сообщении...
СУБД - MSSQL.
...
Рейтинг: 0 / 0
10.10.2006, 09:50
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043311
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
mcureenab Роман ДынникЛюди, вариант объект-атрибут-значение это не реляционная структура!

Ничего подобного. Это тоже реляционное отношение, но отражающее элементарные функциональные зависимости в предельном случае. То что мы здесь обсуждаем вопрос чисто теоретический. Автор довёл структуру до предельного уровня декомпозиции. Соединяя кортежи мы сможем получить исходные отношения. Т.е. с реляционной точки зрения почти всё Ок, никаких формальных противопоказаний к использованию подхода автора нет, разве что количество отношений скорее всего гораздо больше чем это нужно для устранения всех аномалий. Прочие доводы скорее всего будут явно или не явно связаны с особенностями реализации, которые здесь обсуждать нет смысла.


Что то я не совсем понял, какую структуру вы имели ввиду? Объект-атрибут-значение или полную декомпозицию? это не одно и тоже...
...
Рейтинг: 0 / 0
10.10.2006, 09:56
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043317
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Роман ДынникИмел ли кто-нибудь опыт с подобным решениемПохоже, будете первым:)
...
Рейтинг: 0 / 0
10.10.2006, 09:56
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043342
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
ModelR Роман ДынникИмел ли кто-нибудь опыт с подобным решениемПохоже, будете первым:)
Я думаю что нет... Встречал где то проект с полной декомпозицией вообще всех сущностей, но по моему мнению это уже слишком :)
Я хочу сделать только для истории.
...
Рейтинг: 0 / 0
10.10.2006, 10:03
| Ответить | Цитировать | Написать  
25 сообщений из 58, страница 1 из 3
  1  все
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / полная декомпозиция для истории изменений
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=33&fpage=57&tid=1549280]:
 0ms
get settings:
 11ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 50ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 58ms
get tp. blocked users:
 1ms
others: 281ms
total:  433ms
созд. / загр.: 433ms
x
x
Закрыть


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