-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 回答