|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Тема хранения истории изменений неоднократно обсуждалась, однако некоторые решения все же не были особо затронуты. Итак, как вы относитесь к полной декомпозиции для хранения истории? Имеется довольно разветвленный объект для которого требуется хранить историю изменения каждого атрибута. Если атрибутов много и иерархия объекта вцелом очень большая, то решение на таблице-дубликате для истории окажется слишком расточительным и тяжелым если у объекта в какой то момент времени меняется только один атрибут. Если история должна быть 2-х уровневой, то расточительность еще большая если меняется только 1 атрибут из 100 (допустим). Решение видится в том, чтобы для истории(только для истории) полностью декомпозировать первичные сущности и выделить на каждый атрибут по отдельной таблице. Имел ли кто-нибудь опыт с подобным решением, пожалел ли или наоборот доволен? Какие трудности возникали, с чем пришлось побороться? p/s/ Все остальные способы мне хорошо известны и в форуме достаточно освящены, как то: -таблица-дубликат (без декомпозиции) -история в той же таблице -история в виде структуры объект-атрибут-значение -...прочие вариации на тему предыдущих большая просьба в этой ветке их не затрагивать и не обсуждать. задача/предметная область - зарплатный софт, учетные системы . ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 14:08 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
При условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида Код: plaintext 1. 2. 3.
На каждую таблицу с данными навешиваем триггер, который добавляет запись в таблицу истории LOG. Поле table_id идентифицирует таблицу, в которой изменилась запись с ключом rec_id. Прежнее значение видим в поле old_value. Как-нибудь особо отмещать факт удаления записи. В случае ЗП, лучше не удалять, а помечать для удаления и не применять в расчетах, но хранить в БД. Т.о. нет избыточности, но можно проследить всю последовательность изменения каждой записи. С уважением. PS. Вроде бы это не попадает в "остальные способы", которые вы просили не обсуждать, надеюсь не нафлудил. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 14:28 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида Код: plaintext 1. 2. 3.
ИМХО: - недостает идентификатора измененного атрибута. - с учетом этого факта связывать изменения атрибутов с оригинальной записью средствами SQL будет довольно непросто. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 14:49 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
авторИМХО: - недостает идентификатора измененного атрибута. Совершенно верно. Так давайте же его добавим. Определять его значение будем триггере на изменение записи. Заодно добавим поля для хранения времени и пользователя, выполневшегоо изменения. Ну и IP можно подтянуть при желании :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 14:54 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман ДынникРешение видится в том, чтобы для истории(только для истории) полностью декомпозировать первичные сущности и выделить на каждый атрибут по отдельной таблице. Так понял, на каждое значение поля "атрибут" создаём отдельную таблицу, тогда в таблице для определённого атрибута достаточно хранить пару "объект-значение". Принципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю, а особенности работы с такой структурой следует обсуждать в форуме по конкретной СУБД. Скорее всего будут предложены системные способы протоколирования изменений, так что желание изобретать велосипед отпадёт само собой. Видимо, следует оптимизировать структуру БД и логику приложения, чтобы большие объекты изменялись как можно реже. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:03 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю Действительно :) авторВидимо, следует оптимизировать структуру БД и логику приложения, чтобы большие объекты изменялись как можно реже К сожалению обозначенная предметная область "зарплатный софт" исключает измеение "как можно реже". Ежемесячно вносится и правится большое количество записей. И за каждой из них стоит очень конкретный рубль. С уважением. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:16 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
в R/3 сделано так 1 есть таблица - вид объекта - код объекта - имя поля (можно это и структурировать) - значение до - значение после - автор изменения - дата \ время изменения объяснять атрибуты не нужно, думаю 2 имеется простое api - записать изменение \ считать изменение для объекта и проч. Никто не запрещает использовать и select 3 контроль изменений настраивается в каждой функциональности отдельно. По умолчанию - прописано везде. Для новых разработок надо встраивать - создать новый вид объекта, встроить вызовы api На данный момент в рабочей системе 12 млн. записей, проблем с производительностью нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:31 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
AnS1 На данный момент в рабочей системе 12 млн. записей, проблем с производительностью нет. имеется ввиду таблица с историей :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:32 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю в данном случае имелся ввиду вариант, когда существуют 3 таблицы на все типы, т.е. таблица значений - {ObjectID, AttributeID,DTBegin,DTEnd, Value varchar(255)}, что во многих случает не есть гуд. Я же имел ввиду вариант больше похожий на таблицу-дубликат, но полностью декомпозированную, т.е. для каждого исторического атрибута - таблица (ObjectID,DTBegin, DTEnd,Value [того типа который и используется, а не variant или varchar на все случае жизни]). Атрибут соответственно определяет таблица (т.е. никаких AttributeID!). Отличия, имхо, значительные! Структура более реляционная... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:37 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
AnS1в R/3 сделано так 1 есть таблица - вид объекта - код объекта - имя поля (можно это и структурировать) - значение до - значение после - автор изменения - дата \ время изменения это вариант объект-атрибут-значение! ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:39 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида История соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:45 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман Дынник CalmПри условии, что история нужна только для разбора полетов (сравнительно редко) можно нарисовать таблицу LOG вида История соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике. есть впечатление, что пытаемся все многообразие бизнес-логики впихнуть в метаданные (метатаблицу). Что-то похожее уже делали и не раз для документов, для процессов. Честно говоря, ничего хорошего так и не получили. Берем процесс, смотрим, для каких целей используются в нем исторические значения, проектируем структуру данных, ориентированную на процесс. ИМХО, эффективно и производительно :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 15:51 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман Дынник авторПринципиального отличия от варианта "история в виде структуры объект-атрибут-значение" не наблюдаю в данном случае имелся ввиду вариант, когда существуют 3 таблицы на все типы, т.е. таблица значений - {ObjectID, AttributeID,DTBegin,DTEnd, Value varchar(255)}, что во многих случает не есть гуд. Я же имел ввиду вариант больше похожий на таблицу-дубликат, но полностью декомпозированную, т.е. для каждого исторического атрибута - таблица (ObjectID,DTBegin, DTEnd,Value [того типа который и используется, а не variant или varchar на все случае жизни]). Атрибут соответственно определяет таблица (т.е. никаких AttributeID!). Отличия, имхо, значительные! Структура более реляционная... Концептуально отличий нет. Это только вопрос реализации и результат его исследования сильно зависит от конкретной СУБД. В Оракле таблицу (объект, атрибут, значение) можно секционировать, использовать сжатие индекса, в итоге горизонтальная декомпозиция такой таблицы пойдёт скорее во вред чем на пользу. Это правило будет справедливым для большинства РСУБД, поскольку их разработчики в большей спенени ориетнируются на нормализованные данные (число отношений минимально), чем на декомпозированные до потери смысла. Некоторым компромиссом можно назвать многомерные базы данных. Применительно к задаче журналирования, в них значения атрибутов (или их устойчивых групп) остаются неизменными (таблицы со значениями атрибутов называются измерениями), а исторические изменения связи объекта со значениями атрибутов регистрируются в таблице фактов. Возможно, это твой случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 16:34 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
авторИстория соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике. Позволю предположить, что от этого можно уйти. Это неэффективный подход к делу. С уважением. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 16:52 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Я пытался решать эту задачу (а попутно еще и несколько других). Посмотрите презенатцию , там кое-что есть на эту тему. Я допустил ошибку в структуре данных для хранения древовидных путей (поместил пути целиком в warbinary) - из-за этого поиск поддерева в дереве потребовал FullScan. Я знаю, каким образом изменить структуру данных, чтобы решить конкретно эту проблему (правда, придется переписывать 30% текстов триггеров и хранимых процедур и примерно столько же кода клиентской части). Но там есть еще одна проблема, решения которой я пока не нашел. Это проблема быстродействия на операциях записи. Вся основная информация, фактически, хранится в 6 таблицах. Новые структуры данных не приводят к увеличению числа таблиц, просто появляется еще одно описание метаданных и несколько автоматически генеримых триггерами (на таблице, в которой описываются метаданные) VIEW опять же с автоматически генеримыми текстами instead-триггеров. В главной таблице хранится только мимнимальная системная информация о всех объектах ВООБЩЕ (что-то вроде указателя на любой объект, приведенный к дельфишному типу TObject). Все атрибуты объектов располагаются в другой таблице (в полях типа sql_variant - чтобы можно было хранить данные разных типов), сборка объектов в единое целое производится вьюхами. Главная проблема - это конкурирующая запись в такие структуры при большом числе пользователей. Происходят блокировки индекса, всё страшно тормозит. Идеи просто шикарные (там кроме журнализации решается еще вопрос версионности, вынос конфликтов репликации на уровень бизнес-логики, прямоуголных проекций на иерархические структуры данных, преемственности модифицируемых алгоритмов обработки данных и многого другого), но вот с быстродействием - полная труба... :( Так что... Чапай думает дальше... :) Может быть когда-нибудь что-нибудь и придумаю. А вообще, я убежден, что сегодня назрела реальная необходимость включения подобных механизмов в состав самих СУБД. В принципе, тот же MS SQL имеет журнал транзакций, в котором сохраняется история изменения записей. Требуется всего-навсего предоставить расширение языка T-SQL, с помощью которого SQL Server смог бы производить выборку из своего собственного лога информации о модификации записей. Я полагаю, что при желании вендоры СУБД могли бы это сделать. В предложениях клуба RSUG в адрес MS было включено подобное предложение. MS обещал над ним подумать... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 17:39 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
GaryaТребуется всего-навсего предоставить расширение языка T-SQL, с помощью которого SQL Server смог бы производить выборку из своего собственного лога информации о модификации записей. Я полагаю, что при желании вендоры СУБД могли бы это сделать. В предложениях клуба RSUG в адрес MS было включено подобное предложение. MS обещал над ним подумать... :) В Оракле эта функция называется flashback query. Т.е. запрос состояния БД на момент времени в прошлом. Вот только глубина такого просмотра ограничена. Да и копание в журнале процесс довольно медленный. Так что лучше исторические данные хранить в виде отношений БД, оптимизированных для решения конкретных задач, а навороты использовать к месту, в долгоиграющих отчётах, при восстановлении данных после ошибок пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 18:03 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
mcureenabВ Оракле таблицу (объект, атрибут, значение) можно секционировать, использовать сжатие индекса, в итоге горизонтальная декомпозиция такой таблицы пойдёт скорее во вред чем на пользу. Это правило будет справедливым для большинства РСУБД, поскольку их разработчики в большей спенени ориетнируются на нормализованные данные (число отношений минимально), чем на декомпозированные до потери смысла. Люди, вариант объект-атрибут-значение это не реляционная структура! То что сервера нам дают возможность решать проблемы с производительностью посредством секционирования и прочего не решает множества мелких и не очень проблем при подобном подходе. Такая структура хорошо подходит и имеет право на жизнь когда невозможно на этапе проектирования определить количество атрибутов у объекта и количество типов этих объектов, их иерархию наследования (товары с их свойствами, например). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 18:31 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
2 Garya Да, я смотрел внимательно презентацию пару лет назад, в свое время очень помогло на одном из проектов. Много хороших идей, про оси времени, про группы свойств и расширяемость и т. д. Но все же, имхо, объект-атрибут-значение - это для гибкости и расширяемости. Когда же на этапе проектирования все известно не стоит все унифицировать до 3-х таблиц. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 18:38 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Calm авторИстория соответственно не для разбора полетов, и не для протоколирования, а для использования в бизнес-логике. Позволю предположить, что от этого можно уйти. Это неэффективный подход к делу. С уважением. В том то и вопрос, как эффективней и правильней. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 18:40 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман ДынникЛюди, вариант объект-атрибут-значение это не реляционная структура! Ничего подобного. Это тоже реляционное отношение, но отражающее элементарные функциональные зависимости в предельном случае. То что мы здесь обсуждаем вопрос чисто теоретический. Автор довёл структуру до предельного уровня декомпозиции. Соединяя кортежи мы сможем получить исходные отношения. Т.е. с реляционной точки зрения почти всё Ок, никаких формальных противопоказаний к использованию подхода автора нет, разве что количество отношений скорее всего гораздо больше чем это нужно для устранения всех аномалий. Прочие доводы скорее всего будут явно или не явно связаны с особенностями реализации, которые здесь обсуждать нет смысла. Автору я бы посоветовал получше сформулировать конкретную задачу, сократить количество отношений до необходимомо минимума и определиться с СУБД, на которой он будет её решать, а не бросаться в крайности. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 20:23 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман ДынникВ том то и вопрос, как эффективней и правильней. К БД в отрыве от решаемых задач невозможно применять эти категории. Сформулируй задачи, которые нужно решить с помощью БД, рассмотри варианты БД, и оцени с каким из них задачи решаются правильно и достаточно эффективно. Скорее всего, истина будет не далеко от нормализованной БД, где невозможны определённые классы аномалий изменения при минимальном количестве реляционных отношений. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2006, 20:32 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
задача впринципе обозначена была в первом сообщении... СУБД - MSSQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2006, 09:50 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
mcureenab Роман ДынникЛюди, вариант объект-атрибут-значение это не реляционная структура! Ничего подобного. Это тоже реляционное отношение, но отражающее элементарные функциональные зависимости в предельном случае. То что мы здесь обсуждаем вопрос чисто теоретический. Автор довёл структуру до предельного уровня декомпозиции. Соединяя кортежи мы сможем получить исходные отношения. Т.е. с реляционной точки зрения почти всё Ок, никаких формальных противопоказаний к использованию подхода автора нет, разве что количество отношений скорее всего гораздо больше чем это нужно для устранения всех аномалий. Прочие доводы скорее всего будут явно или не явно связаны с особенностями реализации, которые здесь обсуждать нет смысла. Что то я не совсем понял, какую структуру вы имели ввиду? Объект-атрибут-значение или полную декомпозицию? это не одно и тоже... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2006, 09:56 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
Роман ДынникИмел ли кто-нибудь опыт с подобным решениемПохоже, будете первым:) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2006, 09:56 |
|
полная декомпозиция для истории изменений
|
|||
---|---|---|---|
#18+
ModelR Роман ДынникИмел ли кто-нибудь опыт с подобным решениемПохоже, будете первым:) Я думаю что нет... Встречал где то проект с полной декомпозицией вообще всех сущностей, но по моему мнению это уже слишком :) Я хочу сделать только для истории. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2006, 10:03 |
|
|
start [/forum/topic.php?fid=33&msg=34041735&tid=1549280]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
147ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
others: | 247ms |
total: | 515ms |
0 / 0 |