为了简单起见,想象一个充满了人们互相交谈的房间。一个人对另一个人做出的每个陈述都是该表中的记录,所有这些记录都有一个通过自动增量分配的唯一ID。
但是,并非此房间的每个人都在与其他人交谈。正在进行多次对话。
这些对话需要彼此独特。这样可以防止重复的会话ID被启动,并且该站点会收集所有不属于该人的语句。
或者,在图形表示中:
----------------------------------------------
| MessageID | ConvoID | Sender | Recipients | etc...
----------------------------------------------
| 1 | 1 | A | B |
----------------------------------------------
| 2 | 1 | B | A |
----------------------------------------------
| 3 | 2 | C | D |
----------------------------------------------
| 4 | 1 | A | B |
----------------------------------------------
| 5 | 2 | D | C |
----------------------------------------------
| 6 | 1 | B | E |
----------------------------------------------
| 7 | 3 | E | F |
----------------------------------------------
你实际上可以看到正在发生的对话......与B(ID 1)交谈,他在大约同一时间回复(ID 2)C与D开始新的对话(CID 2) ID 3)。
最终回到B关于某事(ID 4),D最终回应C的早期询问(ID 5)。然后,B与E谈论他在与E谈论之前的相同事情(CID 1),然后E转身并与F联系以开始一个全新的对话。
如果这读起来就像在员工立即终止之前发生的步骤那样,那就不是那样的了,但你并不孤单。
因此,您可以看到每个数据库条目都有唯一的ID(MessageID),但这些消息需要很容易地整理在一起。
我正在寻求的解决方案是允许DB创建一个新的独特的“ConvoID”。这就是为什么我们不能自动增加,或者为什么我们不能强制数据集的唯一性。根据本专栏的性质,必须出现重复,但自动增量可能与我正在寻找的完全相反。
任何有助于我指明正确方向的帮助都会受到重视。
谢谢!
答案 0 :(得分:5)
您可以通过添加Conversations
表来规范化设计。该表将有自己的自动递增列。每当启动新会话时,您都会向Conversations
添加一行,并将其标识符用作ConvoID
。