Как сделать историю данных sql? (изменения данных отчета)

Question

Каждый день я сохраняю (с помощью crontab, php script) информацию об ошибках базы данных. Каждая строка, как: (Bugidentification, дата, название, Кто, и т.д ....)

(например: Bugidentification, дата, название, Кто, и т.д ....

issue1, 2015- 04-01, блабла, счет, и т.д. ...

issue2, 2015-04-01, NNNNNNN, джон, и т.д ...

issue3, 2015-04-01, vvvvvvv, Greg и т.д. ..

issue1, 2015-04-02, blabla, bill, etc ...

issue2, 2015-04-02, NNNNNNN, джон, и т.д ...

issue3, 2015-04-02, vvvvvvv, Марио, и т.д ... (здесь сейчас марио)

issue2, 2015-04-03, NNNNNNN, джон, и т.д ... (issue1 исчезли)

issue3, 2015-04-03, vvvvvvv, лисица и др ... (лисица новая информация)

issue4, 2015-04-03, rrrrrrrr, john и т. д. (выпуск4 является новым)

... .......................................... )

В принципе, если Я беру пример, который я писал выше, результаты должны быть что-то подобное для сравнения между датой 2 апреля и 3 апреля

Новая строка: issue4

Закрытая строка: Issue1

Обновлено строка: Issue3 (с тодом вместо марио)

No change row: Issue2

В моем случае есть сотни строк, и я считаю, что знаю, как это сделать, благодаря php, но мой код будет долгой, как создание циклов foreach, и увидим один за другим, если произойдет какое-либо изменение. Я не уверен, что получаю прямое решение.

Итак, мой вопрос в том, есть ли простой способ сообщить об этих изменениях с помощью «простого» кода (например, специальный запрос sql или любой код проекта или простые функции php?).

Answer 1

В этот дизайн встроено слишком много предположений. И эти предположения требуют, чтобы вы сравнивали строки между разными днями, чтобы сделать предположение в первую очередь - не говоря уже о том, что вам нужно дублировать неизменные строки с одного дня на другой, чтобы поддерживать непрерывную ежедневную запись, необходимую для подачи предположений. Уф.

Правило 1: не строите предположения в конструкции. Если что-то новое, его следует отметить: «ЭЙ! Я здесь новый!» Когда были внесены изменения в данные, «ОК, что-то изменилось. Вот оно». и когда проблема окончательно была закрыта, «ОК, это для меня. Я покончил».

create table Bug_Static(-- Contains one entry for each bug 
    ID  int identity, 
    Opened date not null default sysdate, 
    Closed date [null | not null default date '9999-12-31'], 
    Title varchar(...), 
    Who id references Who_Table, 
    <other non-changing data>, 
    constraint PK_Bug_Static primary key(ID) 
); 
create table Bug_Versions(-- Contains changing data, like status 
    ID  int not null, 
    Effective date not null, 
    Status varchar not null, -- new,assigned,in work,closed,whatever 
    <other data that may change from day to day>, 
    constraint PK_Bug_Versions primary key(ID, Effective), 
    constraint FK_Bug_Versions_Static foreign key(ID) 
     references Bug_Static(ID) 
); 

Теперь вы можете выбрать ошибки и текущие данные (последнее внесенное изменение) в любой день.

select s.ID, s.Opened, s.Title, v.Effective, v.Status 
from Bug_Static s 
join Bug_Versions v 
    on v.ID = s.ID 
    and v.Effective =(
     select Max(Effective) 
     from Bug_Versions 
     where ID = v.ID 
      and Effective <= sysdate) 
where s.Closed < sysdate; 

where s.Closed < sysdate не является обязательной. Это дает вам все ошибки, которые были закрыты в момент выполнения запроса, но не закрыты до этого. Это заставляет закрытые ошибки снова и снова появляться - если это не то, что вы хотите.

Измените значения sysdate на определенную дату и время, чтобы получить данные по мере их появления на дату и время.

Обычно, когда создается ошибка, строка вводится в обе таблицы. Затем в качестве статуса или любых других изменений данных вводятся только новые версии. Если ничто не изменилось в день, ничего не вводится. Затем, когда ошибка окончательно закрыта, поле Closed статической таблицы обновляется, а версия версии closed вставляется в таблицу версий. Я показал поле Closed с двумя вариантами: null или с определенной «максимальной датой» от 31 декабря 9999. Вы можете использовать любой из них, но мне нравится метод максимальной даты. Это упрощает запросы.

Я бы также стоял перед обеими таблицами с несколькими видами, которые соединяются с таблицами. Один из них показывает только последние версии каждой ошибки (Bug_Current) и одну, которая показывает каждую версию каждой ошибки (Bug_History). С триггерами на Bug_Current, это может быть приложение, используемое приложением для изменения ошибок. Это изменило бы, например, обновление любого поля с версией до вставки новой версии.

Дело в том, что это очень гибкий дизайн, который вы можете легко показать только нужные вам данные, как вы хотите, как и в любое время.