关于社交网络的数据库架构，如Facebook

Question

与Facebook一样，我有帖子，评论和用户个人资料。

我认为

  

  

• 帖子和评论不需要用户的详细信息

  

• 仅用户个人资料需要详细信息

  

因此，我将用户信息分为主要和详细信息

这是架构。

问题

  

是否有必要将用户数据分为主要和详细信息？

     

为什么不是或为什么是？

感谢您申请！

Answer 1

我建议您使用单独的表，因为您可能不需要同时使用所有这些信息。你可以这样做，但我想到它，你需要一次所有的数据。

表1（用户身份验证）

此表仅包含登录信息，并包含三列（用户名， hashed_pa​​ssword ， UID ）

因此，您的查询会选择 UID ，其中 user_name 和 hashed_pa​​ssword 匹配。我还建议永远不要在数据库表中存储可读密码，因为这可能会成为安全问题。

表2（基本信息）

此表将包含您在注册时获得的最少量信息，以创建基本配置文件。这些字段包含 UID ，名称， DOB ， zip ， link_to_profile_photo ， 电子邮件以及您想要的任何基本信息。 电子邮件有点特别，因为如果您需要 user_name 作为电子邮件地址，则没有理由让它两次。

表3（扩展信息）

此表格包含用户可输入的任何可选信息，例如 UID 分配的 phone_number ，生物或地址 。

然后，您可以添加任意数量的其他表。一个用于邮政，一个用于评论等。

Post表的示例如下：

post_id ， UID ， the_post ， date_of_post ，赞，等等。

然后是评论

comment_id ， for_post_id ， UID ， the_comment ， date_of_comment ，喜欢，等等。

从长远来看，将它分解成小部分会更有效率。

Answer 2

数据库性能与磁盘搜索时间相关联。磁盘搜索时间是数据库性能的瓶颈。对于大型表，您可能需要大量的搜索时间来查找和读取条目。对于帖子和评论，您不需要用户详细信息，只需要用户主要信息，当您只读取帖子和评论的用户ID时，您可能会缩短阅读时间。与user_main_info的连接也会更快。您可以在一个表上保留最常读取的最小数据部分，并在另一个表上保留其他详细信息。但是，在您总是需要一起阅读所有用户信息的情况下，这不会给您带来任何好处。

Answer 3

1）将添加用户信息表

ex:create table fb_users
(intuserid primary key,
username varchar(50),
phoneno int,
emailid varchar(max))

2）发送好友请求

2.a）创建名为friends，朋友请求者，请求的朋友，状态b / w两者的表名，Active flag

ex:create table fb_friends
(intfriendid primary key,
intfriendrequestor int (foreign key with fb_users's(intuserid)),
intfriendrequestedby int (foreign key with fb_users's(intuserid)),
statusid varchar(max)(use the status id from the below table which is a look up table),

active bit)

3）为状态

创建表

3.a）创建名为status，statusname，statusdesc，Active flag

的表名

ex:create table fb_staus
(intstatusid primary key,
statusname varchar,
statusdesc varchar,
active bit)

状态可能是

未决 赞同 删除 ..等

4）类似于创建群组，喜欢，评论

将分别为每个表创建一个表，并从user表创建intuserid的外键 是为每个人链接