|
|
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
Всем привет. Есть таблица которая хранит документы одного типа которые можуи быть как утверждёны так и не утверждён. Таблица следующиего вида: НомерДокумента. НомерЗаказа. КемСоздан. КогдаСоздан. ДанныеДокумента Утверждён? (Да/Нет/НеУтверждался) КемУтверждён. КогдаУтверждён. КоментарийУтверждения. В данной таблице по такому принципу составлено множество документов. Нужно составить отчёт который покажет в какой последовательности происходила работа с докуменами по определённому заказу. К примеру по заказу 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 просто на них ссылкаться? Какие у кого идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 13:47 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
Все что относится к событию - в таб. События примерно так, Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 15:03 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
История может занимать много места, поэтому тотальное логирование лучше сразу не делать для всех типов объектов (не документов), документы - одна сущность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 11:53 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
Валентин К, Хотел бы поднять тему! Есть что то похожее на структуру предложенную Nant't. Все вроде бы правильно. Имеем следующее положение дел: 1. У документа фактически есть текущее состояние которое определяется последней записью documents_history и значением поля "Что произошло"(оно представляет собой значение из справочника). 2. При выводе списка документов в качестве еще одного атрибута показывается его текущее состояние. Это нетрудно, вытащить последнюю запись и достать значение нужного поля. Вот тут внимание. пока проблем нет, но это поле получилось вычисляемым. 3. Требуется вывести список документов по условию Код: plaintext А вот тут в п3 перед тем как покажется результат сервер сперва выполнит калькуляцию для этого поля по всем документам. А если их там 1 млн? Каков выход? Материализованные представления, аналитические функции и др прибамбасы, их эффективность и наличие зависят от модели СУБД. Хотелось бы услышать предложения которые бы были относительно архитектуры таблиц. Есть какие нибудь хитрости, у кого какой опыт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2010, 12:16 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
Кореец Есть какие нибудь хитрости, у кого какой опыт? Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2010, 12:50 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
АнатоЛой Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости? но тогда получается один и тот же атрибут уже находится в двух местах! Т.е. мы должны сперва вставить запись с этим состоянием в таблицу историй, а потом изменить сам документ проставив ему тоже самое состояние в его поле. INSERT+UPDATE для поддержания соотвесвия между записями в разных таблицах. Аномалия? Ведь тогда теоретически возможна ситуация когда эта запись и текущее состояние в документе не будет соответствовать друг другу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.07.2010, 23:49 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
КореецА вот тут в п3 перед тем как покажется результат сервер сперва выполнит калькуляцию для этого поля по всем документам. А если их там 1 млн? КореецАнатоЛой Поле "Текущее состояние документа" в таблицу документов и соотв. индексы... Какие тут хитрости? Ведь тогда теоретически возможна ситуация когда эта запись и текущее состояние в документе не будет соответствовать друг другу. И процитирую ещё чуть-чуть: "Вам машина с шашечками нужна - или ехать?" Денормализация - достаточно распространённое решение для удовлетворения требованиям производительности. Ещё раз: денормализация как средство очень часто оправдано, если целью является повышение производительности, а другие средства мнее эффективны. За производительность Вы платите возможностью возникновения "аномалии" (или же дополнительными затратами на разработку, чтобы таки этой "аномалии" избежать или уменьшить влияние при её появлении). Вы же будете нервничать, если при вопросе в банке "Какой у моей организации остаток на счёте?" Вам скажут: "Подождите пять минут, сейчас мы за 20 лет сотрудничества с Вами просуммируем все Ваши доходы и расходы по счёту". А если они хранят уже посчитанный остаток на счёте (чтобы бчстро отвечать на подобные вопросы) , а сумма истории движения по счёту - это то же самое число, то (О БОЖЕ!) в банке может возникнуть "аномалия", когда эти 2 числа по Вашему счёту не сойдутся! Не страшно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2010, 11:31 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
АнатоЛой ...когда эти 2 числа по Вашему счёту не сойдутся! Не страшно? Как клиенту этого банка страшно)) В чем то вы конечно правы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2010, 12:50 |
|
||
|
Как правильнее хранить историю изменений.
|
|||
|---|---|---|---|
|
#18+
Nerian Но тогда получиться дублирование... Например Коментарий будет присутствовать сразу в двух местах. Это нормально. Разные версии документа, это разные записи в БД. Просто нужно абстрагироваться от представления документа как неделимого множества версий, а перейти к рассмотрению версии документа, как единицы учёта. Зависимости между версиями, это не задача СУБД. Тут придётся логику приложения привлекать. NerianДа и потом при изменении документа надо будет искать это действие в истории и изменять там... Это ещё зачем? История должна оставаться неизменной. Что случилось, то случилось. С другой стороны, если документ имеет вполне определённый жизненный цикл с предопределённым числом состояний, то можно отслеживать переходы состояний документа, просто последовательно заполняя поля в записи. создан date, создатель references user, утверждён date, резолюционер references user, резолюция number, -- принят, отклонён, на доработку. и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2010, 14:34 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34109292&tid=1542613]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
178ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 526ms |

| 0 / 0 |
