我正在开发一个基于 Twitter 的应用程序,为一家公司提供技术支持
所以,工作流程是这样的
1- Twitter 用户提及该公司。
2- 管理员收到通知。
3- 开始与客户一起使用 DM。
所以,我对最好的 ER 模型有点困惑。
为了获得数千条记录,我应该将推文和 DM 存储在同一个表中还是应该将它们分开?
我正在开发一个基于 Twitter 的应用程序,为一家公司提供技术支持
所以,工作流程是这样的
1- Twitter 用户提及该公司。
2- 管理员收到通知。
3- 开始与客户一起使用 DM。
所以,我对最好的 ER 模型有点困惑。
为了获得数千条记录,我应该将推文和 DM 存储在同一个表中还是应该将它们分开?
您的模型几乎没有实体,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)