微信朋友圈表結構設計

『壹』 微信朋友圈資料庫模式如何設計的

你好
因為規則很簡單：任何信息只有發布者本人的好友可見（准確的說是有朋友圈許可權的賬號可見）。誰發布 ，誰的好友可見 ，無論信息是 話題主體或話題下的評論。
所以，解決方案也應該比較簡單。
比如：背後的表可以是 ：
表1：以好友關系為管理對象的表，key為用戶賬號：userid，好友01id，。。。。
表2：以發布內容為管理對象的表，key為用戶賬號：userid，發布內容編號，發布時間，具體內容數.

『貳』 微信朋友圈資料庫模式如何設計的

其實微信朋友圈的資料庫設計模式無非就是符合了三種設置模式，其中最常用的是第三種。
第一範式（1NF）
在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。
所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行只包含一個實例的信息。例如，對於圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一範式就是無重復的列。
第二範式（2NF）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求資料庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二範式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。
第三範式（3NF）
滿足第三範式（3NF）必須先滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在圖3-2的員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。

『叄』 如何優雅的進行表結構設計

資料庫表的命名
使用名詞作為表名
仔細想想便可發現，資料庫表中存在的所有數據都是現實世界各種操作的結果，它們有的是中間過程結果，有的是最終數據結果。不論怎樣，它們是一份一份沒有任何動作的，靜態的記錄。而表本身就是存儲這些記錄的容器，從這樣的層面理解，表名應該採用名詞的形式是完全符合邏輯的。
比如我們要設計一個存儲用戶邀請的表，invitation 就比 invite 更加的優雅。
相關表採用統一前綴
我們知道，大型系統的設計往往按模塊或者子系統進行劃分，一個一個模塊的處理問題，保證模塊間的低耦合，模塊內的高內聚。資料庫表設計也一樣，我們可以對相關聯的表採用相同的前綴，使開發人員一眼看上去就知道哪幾個表是相關的。
比如對於用戶基本信息表、用戶的詳細信息表和用戶的微信綁定表如下的命名更可取：
user
user_profile
user_wecha
欄位的命名
本節先介紹幾個比較通用的原則，使得欄位的含義更容易理解，描述性更強，之後進行簡單的總結分類，以便讓我們明白這些原則背後的邏輯。
使用動詞被動形式+描述性後綴
通過前面我們知道，資料庫表中的所有記錄都是靜態的結果性數據，它是由一定的用戶操作產生的。那麼它是如何產生的？經過什麼樣的操作產生的呢？
在解答之前先看一個例子，下面是一個簡單的 article 表結構：
id: integer
title: varchar
content: text
user_id: integer
create_time: timestamp
這樣的設計本身是沒有問題的，目前用的也很多。這個設計主要的問題是沒有體現出 user_id 與這篇文章的關系，需要經過一定的猜測和思考才能得出。create_time 雖然還比較直觀，但沒有體現出這篇文章實在過去的某個時間創建的。
然後我們在來看修改後的設計：
id: integer
title: varchar
content: text
created_by: integer
created_at: timestamp
通過把 user_id 替換為 created_by、create_time 替換為 created_at，使得我們更容易理解對應的文章是被指定的人在指定的時間創建出來的，而不需要我們的多方猜測或者查閱文檔，使得整個表結構的描述性更強。
時間區分當前時間和未來時間
英語中表時間的時候， at 一般跟一個時間點，而 in 有表示在未來的某個時間之內的意思。結合起來，筆者傾向於用 at 表示過去或者現在的時間，而用 in 表示未來的時間。比如日歷中的 event 有開始時間和結束時間的概念，我覺得如下的命名是比較合理的：
starts_at 事件的開始時間，相對 ends_in 它屬於當前時間，採用 _at 後綴
ends_in 事件的結束時間，相對 ends_in 它屬於未來時間，從用 _in 後綴
其他我們比較常用的比如 created_at、updated_at、expires_in 都屬於這種類型。
使用第三人稱單數
當我們採用動詞+介詞的時候我更傾向與使用第三人稱單數，因為欄位描述的這個實體是單數的，通過使用第三人稱單數，我們可以自然語言的方式表達出需要的意思。比如以 event 為例，翻譯成英語是這樣的：
The event starts at 2016-05-05 12:00:00
完全符合英語的語法，也表達了想要表達的意思。
區分單數與復數
單數與復數主要是對欄位內容的描述，比如通知（notification）有接收人這個欄位，如果我們需要通知能夠發送給多個人，那麼 receivers 這樣的欄位名稱明顯好於 receiver，因為 receivers 體現了通知可以發送給多個人這一個事實。
前面從四個原則出發介紹了如何讓欄位更具有描述性，簡單總結下來我覺得從語義上來說，欄位可以分為兩種類型：描述性欄位和動作性欄位。
描述性欄位是對對應資料庫記錄（或者說實體）的補充說明，比如以人作為實體，那麼人的身高、體重和血壓就屬於這類描述性欄位。
描述性欄位如果是動詞+介詞的形式，動詞需要採用第三人稱單數的形式，比如 starts_at。然後根據欄位的內容，如果內容有多個元素或實體，我們需要使用復數，否則使用單數形式。
動作性欄位不僅能對所屬實體進行補充說明，還能對這個實體的所涉及操作有所描述。比如我們有 article 這個實體， article 的 created_by 和 created_at 就屬於動作性欄位，因為它不僅表達了 article 的創建者和創建時間這層信息，它還表達了這個 article 是指定的人被創建的，而不是憑空生成的。

『肆』 做一個功能的版本設計，怎麼設計表結構最合理

你好

很高興為你解答

答案是：你可以參考一個開源的版本控制系統，看看他們是怎麼做的。

滿意請採納，謝謝!

『伍』 微信朋友圈的基本數據結構設計是怎麼樣的

因為規則很簡單：任何信息只有發布者本人的好友可見（准確的說是有朋友圈許可權的賬號可見）。誰發布 ，誰的好友可見 ，無論信息是 話題主體或話題下的評論。
所以，解決方案也應該比較簡單。
比如：背後的表可以是 ：
表1：以好友關系為管理對象的表，key為用戶賬號：userid，好友01id，。。。。。。。。
表2：以發布內容為管理對象的表，key為用戶賬號：userid，發布內容編號，發布時間，具體內容數

『陸』 微信朋友圈裡的文字這樣顯示方式是怎樣設計的啊

這是微信在朋友圈裡發表文字和圖片的一個功能，是這樣使用的，打開朋友圈長按上面的相機。他就會讓你發表文章和圖片，你選擇圖片，一次最多隻能選擇九張，你把它們編輯成九宮格的模式就可以了。

『柒』 微信朋友圈資料庫模式如何設計的

1、給所有通訊錄好友做好分組管理：做好備注（怎麼加的你，與你關系的強弱），確定哪些客戶是已成交客戶（做好成交時間及成交金額記錄備注），哪些是待跟進的未成交客戶。
2、對自己的頭像、背景牆、個性簽名、朋友圈內容發布設置，尤其是朋友圈內容發布時，必須要考慮發布內容的時間與好友的生活習慣是否匹配。
3、設置互動及二次轉發機制：通過將設定好的發布內容邀請好友轉發朋友圈、發微信群或者群發好友，獲得對應禮品、贈品、代金券等，尤其建議可以獲得跟用戶息息相關的可以使用的產品實物，通過快遞的方式獲取用戶的聯系方式姓名等，建立資料庫。
4、回到第一步，對新加的好友做好分組管理，並做好備注。如果是推廣微信公眾平台也可以引流到客服個人微信號上。

『捌』 微信列表sql語句設計

select top 1 c_id,主鍵；c_userId發言人Id；c_target_Id,發言對象ID;C_content發言內容;c_Date發言時間 where c_userId='A' or c_target_Id='a' order by date存儲發言時間 desc

『玖』 微信朋友圈的基本數據結構設計是怎麼樣的

邏輯結構是圖，實際上用的是關系資料庫的多對多聯系來管理的