0

整个下午。

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

目前它看起来有点像这样：

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 字段将使用新阶段进行更新。

问题在于这违反了数据库规范化规则，因为票证的当前阶段由票证.stage_id 和票证事件表中的最新记录定义。在我试图写一份报告显示任何时间点的未处理票证数量时，我发现了为什么会这样。似乎很难获得任何类型的 SQL 来快速从事件表中检索当前阶段。

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

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

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

非常感谢。西蒙

4

3 回答 3

0

规范化规则是指导方针。它们适用于许多情况，但不是全部。“违反”规则并不是一件坏事，而在任何情况下都一味地遵守规则绝对是一件坏事。

将它们视为与道路规则相同 - 始终遵守速度限制，留在路边等......但是当迎面而来的逆行醉酒司机身体上时，始终遵守这些规则会使您变成煎饼把他的车和你的车合并了，而你本来可以转入另一条车道。

于 2011-07-18T15:46:45.470 回答
0

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

听起来您需要更多地考虑您的确切要求。

于 2011-07-18T15:49:05.643 回答
0

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

于 2011-07-18T15:52:44.180 回答