Question

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

所以，工作流程就像这样

1- Twitter用户提及该公司。

2-管理员收到通知。

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

所以，我对最佳ER模型有点困惑。

我是否应该将推文和DM存储在同一个表中，还是应该将它们分开，以获得数千条记录？

Answer 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)

ER建模有哪些更好的实践？

1 个答案: