關於 Facebook 等社交網絡的數據庫架構

Question

像 Facebook 一樣，我有帖子、評論和用戶資料。

我覺得

• 帖子和評論不需要用戶的詳細信息

• 只有用戶個人資料需要詳細信息

所以我把用戶信息分為main和detail

這是架構。

題

是否有必要將用戶數據分為主要和詳細信息？

為什么不或者為什么是？

感謝您的申請！

Answer 1

我建議使用單獨的表格，因為您可能一次不需要所有這些信息。 你可以用任何一種方式來做，但我認為它是你一次需要所有數據。

表 1（用戶身份驗證）

該表將僅包含登錄信息並具有三列（ user_name 、 hashed_pa​​ssword 、 UID ）

因此，您的查詢將選擇user_name和hashed_pa​​ssword匹配的UID 。 我還建議永遠不要在數據庫表中存儲可讀密碼，因為這可能會成為一個安全問題。

表 2（基本信息）

此表將包含您在注冊時獲得的最少信息量，以創建基本配置文件。 這些字段將包括UID 、 name 、 DOB 、 zip 、 link_to_profile_photo 、 email和您想要的任何基本信息。 email有點特殊，因為如果您要求user_name是電子郵件地址，則沒有理由重復使用它。

表 3（擴展信息）

該表將保存用戶可以輸入的任何可選信息，如phone_number 、 bio或UID分配的地址。

然后，您可以添加任意數量的其他表格。 一個用於發布，一個用於評論等。

Post 表的示例如下：

post_id 、 UID 、 the_post 、 date_of_post 、 likes等。

然后為評論

comment_id 、 for_post_id 、 UID 、 the_comment 、 date_of_comment 、 likes等。

從長遠來看，將其分解為小部分會更有效。

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、friend requestor、friend requests by、status 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）同樣用於創建組，喜歡，評論也

將分別為他們每個人創建一個表，並為每個人鏈接用戶表中的 intuserid 的外鍵