ReSQL.ru
     
powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / полная декомпозиция для истории изменений
58 сообщений из 58, показаны все 3 страниц
  все  
полная декомпозиция для истории изменений
    #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
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043417
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторзадача впринципе обозначена была в первом сообщении...
авторучетные системы.
...
Рейтинг: 0 / 0
10.10.2006, 10:22
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043576
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман Дынник mcureenab Роман ДынникЛюди, вариант объект-атрибут-значение это не реляционная структура!

...

Что то я не совсем понял, какую структуру вы имели ввиду? Объект-атрибут-значение или полную декомпозицию? это не одно и тоже...

С реляционной точки зрения одно и тоже. В случае "Объект-атрибут-значение" количество атрибутов прикладной области не фиксировано структурой БД. Т.е. атрибутами являются колонки "объект", "атрибут", "значение". Просто ещё один уровень абстракции добавлен, не путём декомпозиции модели, а переходом на метамодель.
...
Рейтинг: 0 / 0
10.10.2006, 11:01
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34043589
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Предлагаю рассмотреть конкретную таблицу из прикладной области и операции над ней и её историей. Тогда и станет ясно насколько идея состоятеьна.
...
Рейтинг: 0 / 0
10.10.2006, 11:04
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045059
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
mcureenabПредлагаю рассмотреть конкретную таблицу из прикладной области и операции над ней и её историей. Тогда и станет ясно насколько идея состоятеьна.
Ок, так и поступим. Ниже основная диаграмма, с сильно упрощенным куском предметной области (для примера).
красным - связи реализующие наследование (1-1)
синим - связи (1-n)

желтым - иерархия представляющая в БД BO-сотрудник для которого будем строить историю.
фиолетовым - вспомогательная таблица развертывающая связь n-n вмежду сотрудником и налогом в две связи 1-n и также являющаяся частью BO-сотрудник.
Для упрощения примем что нужна история для атрибутов:
-должность сотрудника
-налоги сотрудника (исторический список)
исходная диаграмма:
...
Рейтинг: 0 / 0
10.10.2006, 17:03
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045064
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
если историю хранить в полностью декомпозированном виде, то получается примерно следующее.
Диаграмма истории:
...
Рейтинг: 0 / 0
10.10.2006, 17:05
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045129
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Роман, это неправильный подход к решению задачи.
Не нужны таблицы "истории".
Нужна таблица с полями "начало срока действия", "конец срока действия" для шт. должностей, для периодов, в которые полагались выплаты. Никаких специальных таблиц, вы погрязните в написании всяких триггеров и "бизнес-логики", там, где это совсем не нужно.

Для налогов и других начислений нужна таблица
авторПериод начислений (месяц)
Налог
Сумма
...
Рейтинг: 0 / 0
10.10.2006, 17:29
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045137
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Сформулируйте-таки четко для себя зачем вы хотите "историю", и вы сами поймете, что никаких супер-финтов делать не надо.
...
Рейтинг: 0 / 0
10.10.2006, 17:32
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045168
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
авторНикаких специальных таблиц, вы погрязните в написании всяких триггеров и "бизнес-логики",
Триггеров мы не используем, 80% хп-CRUD-слоя бизнес-логики генерится автоматом по модели.
...
Рейтинг: 0 / 0
10.10.2006, 17:39
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045187
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm
Для налогов и других начислений нужна таблица

Период начислений (месяц)
Налог
Сумма
это уже результат расчета в виде журнала.
сами же начисления, которые вы имеете ввиду должны инициироваться исходя из установленных свойств у сотрудника.
...
Рейтинг: 0 / 0
10.10.2006, 17:43
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045218
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
может налоги у сотрудника не совсем понятный пример...
скажем могла бы потребоваться история списка центров затрат/подразделений с разнесением всех начислений по процентам.
Для сущности "налог" нужна история баз (какие начисления входят в налоговую базу).
...
Рейтинг: 0 / 0
10.10.2006, 17:50
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045225
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторсами же начисления, которые вы имеете ввиду должны инициироваться исходя из установленных свойств у сотрудника.

Совершенно верно, и каждое из этих свойств имеет конкретное значение в определенном промежутке времени. Так в ведите в свои таблицы понятия промежутка времени и будет вам "история".

Запрос свойств "на позавчера" не должен ничем отличаться от запроса свойств "на текущий момент". Кроме указания периода времени (расчетного месяца к примеру)


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

Пожалуйста.
Делаем таблицу видов оплат и таблицу налогов (на самом деле налоги можно рассматривать как частный случай вида оплаты).
В таблицу отношения многие-ко-многим добавьте поля "дата с.." и "дата по..".
Поверьте, многое упростится :)

Как бы не менялось формирование баз налогов, это можнжо будет посмотреть на любой момент времени.
...
Рейтинг: 0 / 0
10.10.2006, 17:56
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045250
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
CalmСформулируйте-таки четко для себя зачем вы хотите "историю", и вы сами поймете, что никаких супер-финтов делать не надо.
Формулирую:
Хочу историю для того чтобы, к примеру:
1. правильно производить расчет налогов если налоговые базы меняются задним числом
2. правильно автоматом начислять/доначислять/сторнировать оклад если оклад меняется задним числом или центр затрат сотрудника меняется с середины месяца.
3. хочу иметь возможность хранить 2-х уровневую историю (история истории) - опять таки нужна для расчетов.

при этом хочу определенным ролям запретить на уровне слоя хп менять историю определенных атрибутов.
и как приятный дополнительный эфект получить протоколирование действий пользователей.
...
Рейтинг: 0 / 0
10.10.2006, 17:59
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045275
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
автор Так в ведите в свои таблицы понятия промежутка времени и будет вам "история".
То о чем вы говорите, это вариант хранения истории в той же таблице.
На форуме неоднократно обсуждалось и имеет много негативных последствий.
Как одно из самых неприятных - отказ от ссылочной целостности на уровне БД.
...
Рейтинг: 0 / 0
10.10.2006, 18:04
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045306
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторТо о чем вы говорите, это вариант хранения истории в той же таблице.
На форуме неоднократно обсуждалось и имеет много негативных последствий.
У этого способа есть отличное достоинство - он позволяет без осложнений расчитывать ЗП.

авторКак одно из самых неприятных - отказ от ссылочной целостности на уровне БД.
О чем вы говорите?? Зачем, какой отказ???
...
Рейтинг: 0 / 0
10.10.2006, 18:11
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045325
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
автор1. правильно производить расчет налогов если налоговые базы меняются задним числом
2. правильно автоматом начислять/доначислять/сторнировать оклад если оклад меняется задним числом или центр затрат сотрудника меняется с середины месяца.
Вы хорошо видите проблемы расчета ЗП.
Пожалуйста, вы это получите.


авторпри этом хочу определенным ролям запретить на уровне слоя хп менять историю определенных атрибутов.
И этому нет припятсвий!

авторхочу иметь возможность хранить 2-х уровневую историю (история истории) - опять таки нужна для расчетов.

История ради истории, "потому что нужно".
Вы как будто в плену какой-то парадигмы и не хотети видеть иного.
...
Рейтинг: 0 / 0
10.10.2006, 18:16
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045331
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
CalmО чем вы говорите?? Зачем, какой отказ???
давайте с простого:
какие записи и в какой таблице будут если должность сотрудника
с 01.01.2006 по 31.01.2006 инженер
с 01.02.2006 по 31.12.2007 ведущий инженер
?
...
Рейтинг: 0 / 0
10.10.2006, 18:16
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045381
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm
История ради истории, "потому что нужно".
Вы как будто в плену какой-то парадигмы и не хотети видеть иного.
Да нет... во многих системах существует понятия рабочей даты и учетной даты + еще текущей даты.
Для чего это нужно:
допустим сегодня 01.03.2006
в истории оклада для сотрудника установлено что
01.01.2006 - 31.01.2006 оклад 100р.
01.02.2006 - 28.02.2006 оклад 200р.
теперь 01.03.2006 обнаруживается что 01.01.2006 - 31.01.2006 оклад должен быть 150, а не 100, но расчеты уже завершены.
Будете считать оклады с начала года как налоги? А если не оклады, а куча других начислений? Ручным сторнированием - сколько записей засторнировать придется?
Вот Garya - как одно из возможных решений ввел для этого понятие осей времени.
...
Рейтинг: 0 / 0
10.10.2006, 18:28
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045383
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
[quot Calm]
У этого способа есть отличное достоинство - он позволяет без осложнений расчитывать ЗП.
[quot]
поверьте мне что я отлично знаю и вполне ощутил на себе "достоинства" этого способа...
...
Рейтинг: 0 / 0
10.10.2006, 18:29
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045409
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторкакие записи и в какой таблице будут если должность сотрудника
с 01.01.2006 по 31.01.2006 инженер
с 01.02.2006 по 31.12.2007 ведущий инженер

Незнаком с конкретно вашей реализации, так что будем терпимы друг к другу :)
Если говорим просто о названии шт. должности, то это можно поместить в таблицу
Сотрудник_К_ШтДолжности. Причем именно так, как вы нарисовали.
автор

допустим сегодня 01.03.2006
в истории оклада для сотрудника установлено что
01.01.2006 - 31.01.2006 оклад 100р.
01.02.2006 - 28.02.2006 оклад 200р.
теперь 01.03.2006 обнаруживается что 01.01.2006 - 31.01.2006 оклад должен быть 150, а не 100, но расчеты уже завершены.
Будете считать оклады с начала года как налоги?

Да, буду, пересчитывать с месяца, за который произошло изменение.
При расчете ЗП изменения задним числом вносятся часто.

сколько записей засторнировать придется?
Какую проблему я не вижу?
...
Рейтинг: 0 / 0
10.10.2006, 18:36
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045416
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
Извините, недописал предыдущий пост
авторколько записей засторнировать придется?

Какую проблему я не вижу?
Сколько надо, столько прога и просторнирует.

С уважением.
...
Рейтинг: 0 / 0
10.10.2006, 18:37
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045436
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторповерьте мне что я отлично знаю и вполне ощутил на себе "достоинства" этого способа...
я тоже :)
Только без кавычек. Может дело в том, как их готовить? :)

Давайте обсудим, в чем недостатки? В раздутости таблиц? Но для ЗП нужны данные за предыдущие периоды, это факт.

И о какой утрате ссылочной целостности вы упоминали?
...
Рейтинг: 0 / 0
10.10.2006, 18:44
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045444
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm
Да, буду, пересчитывать с месяца, за который произошло изменение.
При расчете ЗП изменения задним числом вносятся часто.

Как вы узнаете что произошло изменение и с какого месяца нужно пересчитать если у вас только 2-е даты С и ПО?
Как это понять, если в данной ситуации вы просто меняете строку
01.01.2006 - 31.01.2006 оклад 100р.
на строку
01.01.2006 - 31.01.2006 оклад 150р.
Тут нужно как то понять когда это изменение прошло. Для этого и существуют два понятие - учетной и рабочей даты. Вот как раз рабочая дата и нужна еще в этой истории чтобы определить с какого месяца пересчитать все нужно. иначе придется пересчитывать с начала года.
...
Рейтинг: 0 / 0
10.10.2006, 18:45
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045450
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm
Может дело в том, как их готовить

может..., я повором не был :)
...
Рейтинг: 0 / 0
10.10.2006, 18:48
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045453
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
CalmДавайте обсудим, в чем недостатки? В раздутости таблиц? Но для ЗП нужны данные за предыдущие периоды, это факт.

Нужны. каждый вариант имеет право на существование. в одном случае - вертикальная раздутость, в другом - горизонтальная.
...
Рейтинг: 0 / 0
10.10.2006, 18:50
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045473
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
Calm
И о какой утрате ссылочной целостности вы упоминали?

для штатного расписания пример надуманный, но все же если в этом контексте...
Когда к строке штатного расписания нужно сделать связь 1-1 или 1-n.
Получается что состояние разнесено во времени и на этапе проектирования создать связь не получится. Связи приходится делать программно, в том числе и для того чтобы получить состояние на текущий момент времени. Надеюсь что доступно объяснил ).
...
Рейтинг: 0 / 0
10.10.2006, 18:57
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045479
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторКак вы узнаете что произошло изменение и с какого месяца нужно пересчитать если у вас только 2-е даты С и ПО?
Как это понять, если в данной ситуации вы просто меняете строку
01.01.2006 - 31.01.2006 оклад 100р.
на строку
01.01.2006 - 31.01.2006 оклад 150р.

Дык если взять месяц из "даты с", это и будет месяц, с которого надо пересчитать :)

Надо правильно соединять оклады и людей. Можно сделать связь между сотрудников и разрядом тарифной сетки. Поменяли тарифную сетку, пересчитали людей. ТС кстати задним числом менять не положено.

Можно сумму выплаты (скажем, доплату какую-нибудь за вредность) хранить как свойство сотрудника. Скажем, в мае заплатили (была привязка к челу с 1 мая по 31), а в июне сообразили, что никакой вредности не было. Тут и вовсе сразу понятно, что май надо пересчитывать, а не с января.

Или притащил чел в сентябре справку об инвалидности, действующую с июля (нудно это дело, мед комиссии). Значится с мая и пересчитаем.
Не проблема это, определить с какого месяца пересчет нужен.

Ну а если в марте приказано уменьшить ставку НСП и ПЗ, то тоже все понятно - весело пересчитываем всех с января (тут как бы совпало с началом года, но важен факт тот, что при изменении данных мы точно определяем, когда надо пересчитывать).


P.S. Опять же, мне не видна предполагаемая арихитектура вашего решения, поэтому может быть несколько запутано может показаться..
...
Рейтинг: 0 / 0
10.10.2006, 19:01
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045487
Фотография Calm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calm
Участник
авторв одном случае - вертикальная раздутость, в другом - горизонтальная.
Но разве горизонтальная раздутость раздувает не только объем данных (да разве это сегодня проблема?), но усложняет логику программы, удлиняет срок разработки, создает десятки постов на форумах :) ?

авторНадеюсь что доступно объяснил
Боюсь, что нет. Видимо пора мне отдыхать идти :)

авторКогда к строке штатного расписания нужно сделать связь 1-1 или 1-n.
На всякий случай замечу, что шт.должности и сотрудники должны связываться многие-ко-многим. Т.к. есть внутренние совместители.

авторкаждый вариант имеет право на существование.
Безусловно так, на том и порешим :)
...
Рейтинг: 0 / 0
10.10.2006, 19:07
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34045542
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман Дынник Calm
Для налогов и других начислений нужна таблица

Период начислений (месяц)
Налог
Сумма
это уже результат расчета в виде журнала.
сами же начисления, которые вы имеете ввиду должны инициироваться исходя из установленных свойств у сотрудника.

ИМХО, ты в своей модели упустил ряд важных сущностей, и закрыл эту дыру в анализе некими абстрактными историями.

Налоги и должности это не свойство сотрудника.

Должность определяется записью в трудовой книжке. Опиши такую сущность и никакой истории не потребуется, поскольку запись в трудовой книжке имеет дату.

Налоги определяются налоговым законодательством и налоговой базой.
В системе нужно обеспечить учёт всех фактов, которые учитываются при начислении налога. Например документы подтверждающие факты страхования жизни, оплату обучения, покупку жилья и т.п. И создать процедуру, которая на основании этих данных будет расчитывать налог и отражать его на лицевом счёте сотрудника.
...
Рейтинг: 0 / 0
10.10.2006, 19:38
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34046137
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
mcureenabИМХО, ты в своей модели упустил ряд важных сущностей, и закрыл эту дыру в анализе некими абстрактными историями.

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

mcureenab, Calm , пожалуйста, давайте более абстрактный разговор вести, особо не погружаясь в предметную область зарплаты.
...
Рейтинг: 0 / 0
11.10.2006, 09:36
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34046210
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Роман Дынник
Участник
CalmНо разве горизонтальная раздутость раздувает не только объем данных (да разве это сегодня проблема?)
Это в определенных ситуациях может быть большой проблемой для DBA .
Например, если у вас есть штук 100 никак не связанных между собой компаний и на каждую компанию своя база и в каждой такой базе здоровая такая partitioned view истории, секции которой в некоторых случаях требуется разнести по разным серверам... Потом как то надо идти на компромис при выборе полей секционирования поскольку данные все в одной куче. Чаще всего выбираются даты. и если вам надо выбрать всю историю для определенного атрибута получается полный скан всех секций, вот тогда секционирование проблем с производительностью не решит.
...
Рейтинг: 0 / 0
11.10.2006, 10:02
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34046844
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Если бы вместо наукообразного термина декомпозиция , использовалось простое и понятное слово, детализация , то публике было бы более понятна суть.имхо
...
Рейтинг: 0 / 0
11.10.2006, 12:36
| Ответить | Цитировать | Написать  
полная декомпозиция для истории изменений
    #34047661
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Роман Дынник mcureenab, Calm , пожалуйста, давайте более абстрактный разговор вести, особо не погружаясь в предметную область зарплаты.

ИМХО, абстрактные рассуждения ограничиваются тем, что так делать можно. Далее нужно рассматривать приложения теории, дабы оценить границы её практической применимости.
...
Рейтинг: 0 / 0
11.10.2006, 15:13
| Ответить | Цитировать | Написать  
58 сообщений из 58, показаны все 3 страниц
  все  
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / полная декомпозиция для истории изменений
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=33&tid=1549280]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 153ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 118ms
get tp. blocked users:
 1ms
others: 244ms
total:  564ms
созд. / загр.: 564ms
x
x
Закрыть


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