Система заявок поддержки событий на основе событий MySQL

Днем все.

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

На данный момент это выглядит примерно так:

create table tickets (
    ticket_id int not null primary key auto_increment,
    stage_id int not null default 0,
    name varchar(255) not null default ''
    /* etc... */
);
create table ticket_events (
    event_id int not null primary key auto_increment,
    ticket_id int not null,
    date datetime,
    stage_id
);
create table stages (
    stage_id int not null primary key auto_increment,
    name varchar(255)
);

Таким образом, всякий раз, когда билет изменяет этап, в таблицу ticket_events добавляется новая строка, указывающая, на какой этап он был перемещен и когда, а поле stage_id в таблице заявок обновляется с новым этапом.

Проблема заключается в том, что это нарушает правила нормализации базы данных, поскольку текущая стадия заявки определяется как tickets.stage_id, так и самой последней записью в таблице ticket_events. В моей попытке написать отчет, показывающий количество неоплаченных билетов в любой момент времени, я обнаружил, почему это так. Кажется, что очень сложно получить какой-либо SQL для быстрого извлечения текущего этапа из таблицы событий.

Мне удалось построить достаточно быстрый запрос, используя вариант 2 на этой очень полезной странице (http://kristiannielsen.livejournal.com/6745.html), но я столкнулся с проблемой, которая застряла у меня.

С текущими данными event_id не всегда выполняется в порядке возрастания относительно даты. Кроме того, из-за определенных сценариев автоматической обработки вполне возможно, что в одном билете есть два события с точно одинаковыми датами. Это означает, что любой запрос, пытающийся использовать таблицу событий, должен "упорядочивать по дате, event_id", что практически невозможно сделать с подзапросами и группировкой.

Кто-нибудь может дать какой-нибудь совет относительно того, как я мог бы преодолеть эти проблемы? Есть ли лучший способ определения порядка событий?

Большое спасибо. Саймон

Источник

3 ответа

Решение

Я бы заменил tickets.stage_id на FK для таблицы ticket_events (last_event), и всякий раз, когда вставляется новое событие, триггер обновляет поле tickets.last_event до PK события. Это позволяет легко / быстро соединиться, чтобы найти текущий этап из таблицы событий.

Источник

Правила нормализации являются руководящими. Они применяются во многих ситуациях, но не во всех. "нарушение" правил автоматически не является плохой вещью, а рабское следование им во всех ситуациях - определенно плохая вещь.

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

Источник

Другим способом сделать это было бы иметь "следующий идентификатор события" в таблице заявок. Когда вы создаете событие, вы его используете, а затем обновляете. Затем вы можете установить свой собственный независимый порядок. В качестве альтернативы, вы можете иметь поле "приоритет", которое будет действовать как вторичный порядок, когда дата / время совпадают.

Похоже, вам нужно подумать немного больше о ваших точных требованиях.

Источник
Другие вопросы по тегам