Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как правильнее хранить историю изменений. / 9 сообщений из 9, страница 1 из 1
07.11.2006, 13:47
    #34109043
Nerian
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
Всем привет. Есть таблица которая хранит документы одного типа которые можуи быть как утверждёны так и не утверждён. Таблица следующиего вида:

НомерДокумента.
НомерЗаказа.
КемСоздан.
КогдаСоздан.
ДанныеДокумента
Утверждён? (Да/Нет/НеУтверждался)
КемУтверждён.
КогдаУтверждён.
КоментарийУтверждения.

В данной таблице по такому принципу составлено множество документов.
Нужно составить отчёт который покажет в какой последовательности происходила работа с докуменами по определённому заказу. К примеру по заказу XXX:

Дата / Документ / ЧтоПроизошло / Кем / Результат / Коментарий
01.01.01 / 1000 / Создан / Пользователь1 / Успешно / Нету
02.01.01 / 1001 / Создан / Пользователь1 / Успешно / Нету
03.01.01 / 1002 / Создан / Пользователь2 / Успешно / Нету
04.01.01 / 1001 / Утверждение / Пользователь1 / Успешно / Нету
05.01.01 / 1000 / Утверждение / Пользователь1 / Неуспешно / (Неутвердил)
06.01.01 / 1002 / Утверждение / Пользователь2 / Успешно / Нету

Единственное что пока пришло в голову это создать дополнительную таблицу
в которую писать что и когда было произведено и записывать туда результат.
Но тогда получиться дублирование... Например Коментарий будет присутствовать сразу в двух местах. Да и потом при изменении документа надо будет искать это действие в истории и изменять там...

Тоесть пока что в голову пришла идея:
create table documents(
Номер INT NOT NULL AUTO_INCREMENT,
НомерЗаказа INT NOT NULL,
ДатаСоздания DATETIME,
КемСоздано INT NOT NULL,
Данные VARCHAR(255),
РезультатУтверждения SMALL INT,
КогдаУтверждено DATETIME,
КемУтверждено INT,
КоментарийУтверждения VARCHAR(200)
)

create table documents_history(
НомерДокумента INT NOT NULL AUTO_INCREMENT,
ЧтоПроизошло INT,
КогдаПроизошло DATETIME,
КтоСделал INT,
Результат INT,
Коментарий VARCHAR(200)
)

Может тогда коментарий с результатом выносить в отдельную таблицу типо comments а в таблицах document_history и documents просто на них ссылкаться? Какие у кого идеи?
...
Рейтинг: 0 / 0
07.11.2006, 15:03
    #34109292
Nant
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
Все что относится к событию - в таб. События

примерно так,

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
create table documents(
НомерДокумента INT NOT NULL AUTO_INCREMENT,
НомерЗаказа INT NOT NULL,
Данные VARCHAR( 255 ),
)

create table documents_history(
НомерСобытия INT NOT NULL AUTO_INCREMENT,
НомерДокумента INT NOT NULL,
ЧтоПроизошло INT,
КогдаПроизошло DATETIME,
КтоСделал INT,
Результат INT,
Коментарий VARCHAR( 200 )
)
...
Рейтинг: 0 / 0
10.11.2006, 11:53
    #34118883
Валентин К
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
История может занимать много места, поэтому тотальное логирование лучше сразу не делать для всех типов объектов (не документов), документы - одна сущность.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
22.07.2010, 12:16
    #36754154
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
Валентин К,


Хотел бы поднять тему!


Есть что то похожее на структуру предложенную Nant't.
Все вроде бы правильно.

Имеем следующее положение дел:

1. У документа фактически есть текущее состояние которое определяется последней записью documents_history и значением поля "Что произошло"(оно представляет собой значение из справочника).

2. При выводе списка документов в качестве еще одного атрибута показывается его текущее состояние. Это нетрудно, вытащить последнюю запись и достать значение нужного поля.
Вот тут внимание. пока проблем нет, но это поле получилось вычисляемым.

3. Требуется вывести список документов по условию
Код: plaintext
 ..... where "Что произошло" = ''Закрыт"

А вот тут в п3 перед тем как покажется результат сервер сперва выполнит калькуляцию для этого поля по всем документам. А если их там 1 млн?


Каков выход?

Материализованные представления, аналитические функции и др прибамбасы, их эффективность и наличие зависят от модели СУБД.

Хотелось бы услышать предложения которые бы были относительно архитектуры таблиц.
Есть какие нибудь хитрости, у кого какой опыт?
...
Рейтинг: 0 / 0
22.07.2010, 12:50
    #36754252
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
Кореец
Есть какие нибудь хитрости, у кого какой опыт?
Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости?
...
Рейтинг: 0 / 0
22.07.2010, 23:49
    #36755657
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
АнатоЛой
Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости?

но тогда получается один и тот же атрибут уже находится в двух местах!

Т.е. мы должны сперва вставить запись с этим состоянием в таблицу историй, а потом изменить сам документ проставив ему тоже самое состояние в его поле.
INSERT+UPDATE для поддержания соотвесвия между записями в разных таблицах.


Аномалия? Ведь тогда теоретически возможна ситуация когда эта запись и текущее состояние в документе не будет соответствовать друг другу.
...
Рейтинг: 0 / 0
23.07.2010, 11:31
    #36756106
АнатоЛой
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
КореецА вот тут в п3 перед тем как покажется результат сервер сперва выполнит калькуляцию для этого поля по всем документам. А если их там 1 млн?


КореецАнатоЛой
Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости?
Ведь тогда теоретически возможна ситуация когда эта запись и текущее состояние в документе не будет соответствовать друг другу.

И процитирую ещё чуть-чуть: "Вам машина с шашечками нужна - или ехать?"

Денормализация - достаточно распространённое решение для удовлетворения требованиям производительности. Ещё раз: денормализация как средство очень часто оправдано, если целью является повышение производительности, а другие средства мнее эффективны. За производительность Вы платите возможностью возникновения "аномалии" (или же дополнительными затратами на разработку, чтобы таки этой "аномалии" избежать или уменьшить влияние при её появлении). Вы же будете нервничать, если при вопросе в банке "Какой у моей организации остаток на счёте?" Вам скажут: "Подождите пять минут, сейчас мы за 20 лет сотрудничества с Вами просуммируем все Ваши доходы и расходы по счёту". А если они хранят уже посчитанный остаток на счёте (чтобы бчстро отвечать на подобные вопросы) , а сумма истории движения по счёту - это то же самое число, то (О БОЖЕ!) в банке может возникнуть "аномалия", когда эти 2 числа по Вашему счёту не сойдутся! Не страшно?
...
Рейтинг: 0 / 0
23.07.2010, 12:50
    #36756325
Кореец
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
АнатоЛой

...когда эти 2 числа по Вашему счёту не сойдутся! Не страшно?

Как клиенту этого банка страшно))

В чем то вы конечно правы.
...
Рейтинг: 0 / 0
23.07.2010, 14:34
    #36756611
mcureenab
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Как правильнее хранить историю изменений.
Nerian
Но тогда получиться дублирование... Например Коментарий будет присутствовать сразу в двух местах.

Это нормально. Разные версии документа, это разные записи в БД. Просто нужно абстрагироваться от представления документа как неделимого множества версий, а перейти к рассмотрению версии документа, как единицы учёта.
Зависимости между версиями, это не задача СУБД. Тут придётся логику приложения привлекать.


NerianДа и потом при изменении документа надо будет искать это действие в истории и изменять там...


Это ещё зачем? История должна оставаться неизменной. Что случилось, то случилось.

С другой стороны, если документ имеет вполне определённый жизненный цикл с предопределённым числом состояний, то можно отслеживать переходы состояний документа, просто последовательно заполняя поля в записи.

создан date,
создатель references user,
утверждён date,
резолюционер references user,
резолюция number, -- принят, отклонён, на доработку.
и т.д.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как правильнее хранить историю изменений. / 9 сообщений из 9, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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