-2

我正在开发一个基于 Twitter 的应用程序,为一家公司提供技术支持

所以,工作流程是这样的

1- Twitter 用户提及该公司。

2- 管理员收到通知。

3- 开始与客户一起使用 DM。

所以,我对最好的 ER 模型有点困惑。

为了获得数千条记录,我应该将推文和 DM 存储在同一个表中还是应该将它们分开?

4

1 回答 1

1

您的模型几乎没有实体,user_id 表示撰写推文的用户的 ID:

基本结构

Message (id, message, user_id, date etc)
User (id, name, employee_id?, etc)

提到的单个帐户

然后你有一个事实,可能会发生提及,这是消息的一个属性,因此你可以为此添加一个列:如果你只想拥有一个帐户,则提到 BOOL。会给:

Message (id, message, user_id, date, BOOL mentioned, etc)
User (id, name, employee?, etc)

可以提及多个帐户

另一种形式可能更灵活,添加一个表格帐户,允许存储您想要提及的帐户:

Account (id, name)
Message (id, message, user_id, date, INT account_mentioned, etc)
User (id, name, employee?, etc)

这提供了更大的灵活性,因为您可以添加一个帐户并开始关注提及,例如,您可以通知该帐户的管理员,使您的解决方案更具未来性。

如何与员工相处

根据您的工作流程,您可以说:员工是处理一个或多个帐户的用户。您还可以声明一个帐户由多个用户管理,最后是多个用户管理多个帐户的情况。

本质上,我建议制作一个连接表:

Accounts_Users (account_id, user_id)

例如,您甚至可以在该表中添加角色或优先级。这使您可以完全控制帐户。因为没有给出这部分的信息,所以我无法完全解释。

存储 DM 和公共消息

然后你有 DM 的问题,可以很容易地附加到 Message 实体:

Account (id, name)
Message (id, message, user_id, user_to_id (NULLABLE), date, INT account_mentioned_id, etc)
User (id, name, employee?, etc)

因此,默认情况下,对于消息(推文),user_to_id 列为 NULL,但当它是 DM 时,您在此处添加接收者。这样你就可以找到它们。

为什么把它们都放在一张桌子上?它是具有相同属性的同一实体,它只有一个标志(私有)但本质上是相同的数据。

数据量

...在这个阶段完全无关紧要。本质上,您只需要正确的结构,因此首先对其进行规范化。如果你真的看到性能问题,那么看看如何去规范化一些步骤,但我不希望,对于单个公司的使用,你会遇到这种规范化结构的问题。

您只需要普通的简单连接即可获得所需的数据,并且由于它已标准化,您还可以轻松创建例如一个页面,显示与一个用户(客户端)的所有通信,因为您已标准化。使用此设置很容易获得该数据。

我们处理了数百万条推文,您可以正常化,真的没问题。数据不是很大,所以很多行并不昂贵。

建议最终设置

根据我现在掌握的信息,我会走这条路。

Account (id, name)
Accounts_Users (account_id, user_id)
Message (id, message, user_id, user_to_id (NULLABLE), date, account_mentioned_id, etc)
User (id, name, etc)
于 2012-06-17T10:35:24.293 回答