Database 其他两个中间表之间的中间表的专有名称

我有4个实体：

事件

，

消息

，

流

和

文档

事件

表存储有限（种子）数量的记录<代码>消息有许多事件，每个事件都可以与许多消息相关。为中间表提供了名称

event\u message

如您所见，中间表的约定是：

{tablename}{tablename}

Flow

表存储有限（种子）数量的记录<代码>消息有许多流，每个流可以与许多消息相关。为中间表提供了名称

flow\u message

在

流

和

消息

之间的每个关系上创建一个文档（在

流_消息

上的每个记录）

问题从这里开始：

消息上的每个事件按流具有不同的文档。这意味着：对于中间表

flow\u message

上的每个新记录，中间

event\u message

上的每个记录都有一个新的相关文档

为了解决这个问题，我在

event\u message

和

flow\u message

之间创建了一个中间表，名为：

event\u message\u flow\u message

这是否正确（以某种传统方式）？这个模型正确吗

---

如何通过另外两个中间表正确地建模和命名中间表派生项？

我也希望有一些约定。因为我不知道任何官方惯例，所以我发明了我的。重要的是尊重你选择的惯例

因此，我将

event\u message\u flow\u message

更改为

rel\u eventmessage\u flowmessage

。

---

但对我来说，你的传统很好。

很难推荐，因为我觉得你的模式有点奇怪。在

文档

和

流程消息

以及

文档

和

事件消息

之间都有1:1的关系。在我看来，这很难与

事件\消息\流\消息的多对一关系相协调。如果与
DOCUMENT
的关系实际上是1:1（强制），那么为什么要将文档保存在单独的表中

为了解决您关于表命名的问题：我认为用于命名交集表的{table}{table}约定不是最佳实践，而是在无法想出更好名称的情况下的一种回退

最佳做法是表名反映表中数据记录/描述的事物的业务名称。这样做并不总是可能的，尤其是对于交集表。交集表表示多对多关系，而关系通常很难用名词来描述

在你的情况下，我不认为你的惯例实际上使事情变得特别容易理解。我可能会尝试使用类似于
MESSAGE\u DOCUMENT
的东西来简化，甚至仅仅是
DOCUMENT
——因为它们在任何情况下似乎都是1:1相关的