Ⅰ 千萬級用戶站內簡訊資料庫如何設計
幾條建議：
主體數據建議採用軟刪除
簡訊狀態相關記錄新增一張關聯表記錄
客戶許可權、地區、級別信息採用拉鏈表設計，需要有兩個關鍵欄位，起始和截止時間
Ⅱ 最近做一個站內信，思路是這樣的，信息（發信人，收信人…）和內容兩個表，請問發消息如何操作，先謝謝了
資料庫的設計不是這樣的
一般來說，像你這樣的需求，至少要有以下幾張表：
（1）信息表（2）發送情況表（3）接收情況表（4）作業控製表
Ⅲ 論壇站內信群發，資料庫設計該如何優化
真正的大數據保存在 信息表中， 關聯表式很小的，雖然隨著系統的運行數據會很多 ！！
有兩種方案解決：
1， 及時載入策略：每群發一條消息自然會往消息表中插入一條數據，這時你可以同時往關聯表中插入數據。 好樣的，問題來了！如果系統用戶幾百萬，你發一條站內信，就要往關聯表中插幾百萬條數據，這是很耗性能的！！
2，延遲載入策略：每群發一條消息自然會往消息表中插入一條數據，不要及時插入到關聯表。只當用戶登錄站內信時， 我才將消息表中的未讀消息載入進來。
Ⅳ 站內信的資料庫該如何設計
主鍵（自動編號，用戶id），message內容，日期
Ⅳ sql server2005資料庫，表的設計 站內信 發件人發了一封信能在發件箱刪除它， 而並不影響收件人收件箱
我們網站就有這樣的功能。直接放在一個表中。表中欄位有：ID號，發件人，收件人，發件時間。查看時間。內容。信件狀態。發件人刪除標識。收件人刪除標識。
以上查詢組合起來就成了。按用戶名來進行匹配。如果發件人狀狀和收件人狀態同時設置為了刪除。那這條信息就可以直接從資料庫刪除了。
Ⅵ 站內消息系統數據表怎麼設計
1) 不應該針對整個系統進行資料庫設計，而應該根據系統架構中的組件劃分，針對每個組件所處理的業務進行組件單元的資料庫設計；不同組件間所對應的資料庫表之 間的關聯應盡可能減少，如果不同組件間的表需要外鍵關聯也盡量不要創建外鍵關聯，而只是記錄關聯表的一個主鍵，確保組件對應的表之間的獨立性，為系統或表 結構的重構提供可能性。 2)採用領域模型驅動的方式和自頂向下的思路進行資料庫設計，首先分析系統業務，根據職責定義對象。對象要符合封 裝的特性，確保與職責相關的數據項被定義在一個對象之內，這些數據項能夠完整描述該職責，不會出現職責描述缺失。並且一個對象有且只有一項職責，如果一個 對象要負責兩個或兩個以上的職責，應進行分拆。 3)根據建立的領域模型進行資料庫表的映射，此時應參考資料庫設計第二範式：一個表中的所 有非關鍵字屬性都依賴於整個關鍵字。關鍵字可以是一個屬性，也可以是多個屬性的集合，不論那種方式，都應確保關鍵字能夠保證唯一性。在確定關鍵字時，應保 證關鍵字不會參與業務且不會出現更新異常，這時，最優解決方案為採用一個自增數值型屬性或一個隨機字元串作為表的關鍵字。 4)由於第一點所述的領域模型驅動的方式設計資料庫表結構，領域模型中的每一個對象只有一項職責，所以對象中的數據項不存在傳遞依賴，所以，這種思路的資料庫表結構設計從一開始即滿足第三範式：一個表應滿足第二範式，且屬性間不存在傳遞依賴。 5)同樣，由於對象職責的單一性以及對象之間的關系反映的是業務邏輯之間的關系，所以在領域模型中的對象存在主對象和從對象之分，從對象是從1－N 或N－N的角度進一步主對象的業務邏輯，所以從對象及對象關系映射為的表及表關聯關系不存在刪除和插入異常。 6) 在映射後得出的資料庫表結構中，應再根據第四範式進行進一步修改，確保不存在多值依賴。這時，應根據反向工程的思路反饋給領域模型。如果表結構中存在多值 依賴，則證明領域模型中的對象具有至少兩個以上的職責，應根據第一條進行設計修正。第四範式：一個表如果滿足BCNF，不應存在多值依賴。 7) 在經過分析後確認所有的表都滿足二、三、四範式的情況下，表和表之間的關聯盡量採用弱關聯以便於對表欄位和表結構的調整和重構。並且，我認為資料庫中的表 是用來持久化一個對象實例在特定時間及特定條件下的狀態的，只是一個存儲介質，所以，表和表之間也不應用強關聯來表述業務（數據間的一致性），這一職責應 由系統的邏輯層來保證，這種方式也確保了系統對於不正確數據（臟數據）的兼容性。當然，從整個系統的角度來說我們還是要盡最大努力確保系統不會產生臟數 據，單從另一個角度來說，臟數據的產生在一定程度上也是不可避免的，我們也要保證系統對這種情況的容錯性。這是一個折中的方案。 8)應針 對所有表的主鍵和外鍵建立索引，有針對性的（針對一些大數據量和常用檢索方式）建立組合屬性的索引，提高檢索效率。雖然建立索引會消耗部分系統資源，但比 較起在檢索時搜索整張表中的數據尤其時表中的數據量較大時所帶來的性能影響，以及無索引時的排序操作所帶來的性能影響，這種方式仍然是值得提倡的。 9) 盡量少採用存儲過程，目前已經有很多技術可以替代存儲過程的功能如「對象/關系映射」等，將數據一致性的保證放在資料庫中，無論對於版本控制、開發和部 署、以及資料庫的遷移都會帶來很大的影響。但不可否認，存儲過程具有性能上的優勢，所以，當系統可使用的硬體不會得到提升而性能又是非常重要的質量屬性 時，可經過平衡考慮選用存儲過程。 10)當處理表間的關聯約束所付出的代價（常常是使用性上的代價）超過了保證不會出現修改、刪除、更改 異常所付出的代價，並且數據冗餘也不是主要的問題時，表設計可以不符合四個範式。四個範式確保了不會出現異常，但也可能由此導致過於純潔的設計，使得表結 構難於使用，所以在設計時需要進行綜合判斷，但首先確保符合四個範式，然後再進行精化修正是剛剛進入資料庫設計領域時可以採用的最好辦法。 11)設計出的表要具有較好的使用性，主要體現在查詢時是否需要關聯多張表且還需使用復雜的SQL技巧。 12)設計出的表要盡可能減少數據冗餘，確保數據的准確性，有效的控制冗餘有助於提高資料庫的性能。
Ⅶ asp.net網站怎麼做站內信的群發，不是電子郵件，是通過資料庫做的。求高手提供一個思路。
一個表，叫message，就是存放站內信的，結構如下：
message(id, title, content, sendID,objectID,sendTime,flag)
分別為：ID,標題，內容，發送者ID，接收者ID組(裡面有多個時用逗號分隔，如果為空就是發給所有人的)，發送時間，標志(可用於隱藏，刪除等操作)
如果要發送，就往這個表中插入記錄就可以了。
如果要接收，首先根據ID在objectID里查找，如果objectID為空，就顯示，如果不為空，再查找裡面有沒有這個ID，如果有就顯示，沒有就不顯示；
如果要回復，實際上就取出當前的sendID為objectID，再把自己的用戶ID當作為sendID，再插入這個表。
當然以上表結構是最基礎的，這只是相思種，你也可以把表結構定義的更豐富一些
Ⅷ 關於站內消息系統的一個資料庫表設計
這個可根據需求加幾張表就好，
用戶表，信息表，信息狀態表，你提到1對1，那可能還會有多對多，這種的請最後再有一個和信息關的用戶群表，
欄位么可以根據需求加，如果當心改到有一個土辦法，看看哪個可能有很多功能改進的表多留一些欄位，如果你想欄位好看，那麼就多加一個附表。如果你的系統不太大，不用太當心效率的問題，正常的查詢10萬行的數據只要你sql不是寫得太差，問題都不大的。放開手出做，你在設計的過程中就會有靈感，寫流程圖也會有方向。
額，如果是這樣，說實在你不應該拿到這種地方來討論，如果是30萬用戶的當量的話，那麼做法就完全不同，你有機會處理設計這個表，那麼應該明白，這種表的設計應該是從架構層面來了，如果果這一個比較熱門的網站，這里涉及了負載，同步，表分區，主索引。這里還和你的用的資料庫有關系，用的oracle，mysql，又或是nosql，好像nosql不太合適的樣子，又或別的什麼什麼資料庫，到了一定的數量級的時候就有必要根據數據的優優方向來設計，這邊沒有法說，我也不想寫篇論文（主要是寫不出來），好吧，前面都是廢話。現在可以做的事就是1，去了解你的硬體，有幾台伺服器給你用，2，你是打算做什麼結構的，用什麼編程語言，3，了解功能需要完成的細節，這個表可就不能亂改了。最後，你的問題太坑爹了吧，你這種問題放這來怎麼可能有解決方案嘛，你隨便拿到哪個做這種項目的公司不報個十萬八萬都說不起你，還這不是一個問題。這是一個工程。。。