powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как правильнее хранить историю изменений.
9 сообщений из 9, страница 1 из 1
Как правильнее хранить историю изменений.
    #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
Как правильнее хранить историю изменений.
    #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
Как правильнее хранить историю изменений.
    #34118883
Фотография Валентин К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
История может занимать много места, поэтому тотальное логирование лучше сразу не делать для всех типов объектов (не документов), документы - одна сущность.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Как правильнее хранить историю изменений.
    #36754154
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Валентин К,


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


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

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

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

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

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

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


Каков выход?

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

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

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

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


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


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

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

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

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

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

В чем то вы конечно правы.
...
Рейтинг: 0 / 0
Как правильнее хранить историю изменений.
    #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]