Question

下午全部。

我最近的任务是处理基于事件的支持票证系统，但我遇到了很多问题，我认为问题在于数据库结构。

目前看起来有点像这样：

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从事件表中快速检索当前阶段。

我设法在这个非常有用的页面（http://kristiannielsen.livejournal.com/6745.html）上使用选项2构建了一个相当快速的查询，但我遇到了一个让我陷入困境的问题。

对于当前数据，event_id并不总是按相对于日期的升序运行。此外，由于某些自动处理脚本，很可能一张票有两个日期完全相同的事件。这意味着任何尝试使用事件表的查询都需要“按日期排序，event_id”，这几乎不可能与子查询和分组有关。

任何人都可以就如何克服这些问题提出任何建议吗？有没有更好的方法来定义事件的顺序？

非常感谢。西蒙

Answer 1

规范化规则是指导原则。它们适用于许多情况，但不是全部。 “违反”规则并不是一件坏事，而在所有情况下盲目跟随它们绝对是件坏事。

将它们视为与道路规则相同 - 始终遵循速度限制，保持在路边等等......但是，当那个即将到来的错误方式时，始终遵守这些规则会让你变成煎饼醉酒的司机将你的车与你的车合并，当你可以突然转向另一条车道时。

Answer 2

另一种方法是在票证表上设置“下一个事件ID”。创建事件时，使用该事件，然后更新它。然后，您可以设置自己的独立订单。或者，你可以有一个“优先级”字段，当日期/时间相同时，它将作为次要订单。

听起来你需要多考虑一下你的具体要求。

Answer 3

我将使用FK将tickets.stage_id替换为ticket_events表（last_event），每当插入新事件时，触发器会将tickets.last_event字段更新为事件的PK。这允许轻松/快速联接以从事件表中查找当前阶段。

MySQL基于事件的支持票证系统

3 个答案: