㈠ 聊天軟體的資料庫設計
簡單的設計如下：如需其他功能，需要擴展，
用戶（主鍵，賬號，密碼，郵箱，..）
好友關系（所屬者ID，好友ID）
聊天記錄（主鍵，所屬者ID，好友ID，時間，內容，..）
create table users
(uid number not null primary key,
uname varchar2(50) not null,
pwd varchar2(20) not null,
email varchar2(50) not null,
...)
create table friends
(owerid number not null,
friendid number not null,
constraint fk_owerid poreign key(owerid) references users(uid),
constraint fk_friendid poreign key(friendid) references users(uid),
constraint pk_friendid_owerid primary key(owerid,friendid)
)
create table records
(rid number not null primary key,
owerid number not null,
friendid number not null,
rdate date default sysdate,
rcontents varchar2(4000),
constraint fk_owerid_r poreign key(owerid) references users(uid),
constraint fk_friendid_r poreign key(friendid) references users(uid),
..
)
㈡ 聊天系統的好友列表資料庫如何設計
對於關系資料庫，可以設一個這樣的欄位，這個欄位里存放了李四的所有好友，每個好友以「，」分隔；
對於非關系資料庫，比如說健值消岩資料庫，可以使用一個大型的HASH表來拿衡御存放，攔洞李四的所有好友以一個鏈接的方式串起來 。
比如:
linker表示鏈接
hash(李四)=linker(王五、張三、黃光、李明)
㈢ 微信朋友圈資料庫模式如何設計的
其實微信朋友圈的資料庫設計模式無非就是符合了三種設置模式，其中最常用的是第三種。
第一範式（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）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性。
㈣ 聊天系統-資料庫設計
採用Redis進行數據存儲，主要包括頻控、限流、用戶表、在線用戶表、聊天消息表（redis list實現消息隊列）、好友表（TODO）
CheckFrequency(userId uint64) bool
返回true檢查通過，false觸發頻控
visited_{user_id} >3觸發
離線用戶key為空
數據結構：key-value
取值：
1=在線
2=離開
3=隱身（VIP功能）
數據結構：list
數據結構：hashmap
㈤ 利用JavaWeb設計簡易聊天室，具體要求看補充
利用JavaWeb設計簡易聊天室
這樣你什麼柑橘
比較
㈥ 論壇站內信群發，資料庫設計該如何優化
真正的大數據保存在 信息表中， 關聯表式很小的，雖然隨著系統的運行數據會很多 ！！
有兩種方案解決：
1， 及時載入策略：每群發一條消息自然會往消息表中插入一條數據，這時你可以同時往關聯表中插入數據。 好樣的，問題來了！如果系統用戶幾百萬，你發一條站內信，就要往關聯表中插幾百萬條數據，這是很耗性能的！！
2，延遲載入策略：每群發一條消息自然會往消息表中插入一條數據，不要及時插入到關聯表。只當用戶登錄站內信時， 我才將消息表中的未讀消息載入進來。
㈦ 簡述資料庫應用系統的設計步驟
資料庫設計的基本步驟：
1、系統需求分析與設計。
2、概念結構分析與設計。
3、邏輯結構分析與設計。
4、物理結構分析與設計。
5、系統實施。
6、系統維護。
(7)群聊資料庫設計擴展閱讀：
資料庫設計技巧：
1、原始文件與實體的關系
它可以是一對一，一對多，多對多的關系。一般來說，它們是一對一的關系：一個原始文檔只對應於一個實體。在特殊情況下，它們可以是一對多或多對一關系，即一個原始文檔對應於多個實體，或者多個原始文檔對應於一個實體。
這里的實體可以理解為基本表。在對應關系明確後，對輸入介面的設計非常有利。
2、主鍵和外鍵
一般來說，實體不能既沒有主鍵也沒有外鍵。在E－R圖中，葉中的實體可以定義主鍵或不定義主鍵（因為它沒有子代），但它必須有外鍵（因為它有父項）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國資料庫設計專家說：「鑰匙無處不在，只有鑰匙。」。這是他資料庫設計的經驗，也體現了他對信息系統核心（數據模型）高度抽象的理念。
因為：主鍵是一個高度抽象的實體。主鍵和外鍵的配對表示實體之間的連接。
3、基本表的屬性
基本表不同於中間表和臨時表，因為它具有以下四個特點：
原子性。基本表中的欄位不可分解。
原始主義。基本表中的記錄是原始數據（基本數據）的記錄。
演繹的。所有輸出數據都可以從基本表和代碼表中的數據導出。
穩定。基本表的結構比較穩定，表中的記錄要長期保存。
在了解基本表的性質之後，在設計資料庫時，可以將基本表與中間表和臨時表區分開來。