① 類似QQ空間的社交網站的用戶動態的資料庫應該怎麼設計
動態的結構： { user_id:13, action: 行為, object_id: 對象ID, object_type: 對象類型, object_user_id: 對象用戶ID, parent_object_id: 對象父級ID, parent_object_type: 對象父級類型, parent_object_user_id: 對象父級用戶ID, reply_id: 回復ID, // action為回復時有用 parent_reply_id: 回復的父級回復ID, // action為回復時有用，回復了別人對評論的回復 text: '轉發或者分享時附加文字', view_count: 0, created_at: 創建時間, deleted_at: 刪除時間, } 說明： 1.object_*只存儲主要模塊內容信息，不含評論； 2.parent_object_*存儲有嵌套關系的對象，比如當object_*為答案時，parent_object_*為問題； 3.reply_id用於直接回復評論時用到； 4.parent_reply_id父回復ID; 5. 兩個回復ID，使用情況是：當回復了別人的回復時，根據comment_id拉取評論與全部回復，在模板顯示時只顯示對話的兩個回復。 場景列表： 一級結構： 安正超發布了文章 'action' => NEW, 'user_id' => 安正超ID, 'object_id' => 文章ID, 'object_user_id' => 安正超ID, 'object_type' => ARTICLE, 安正超上傳 了 N張 圖片 'action' => NEW, 'user_id' => 安正超ID, 'object_id' => 圖片ID（數組，以逗號隔開）, 'object_user_id' => 安正超ID, 'object_type' => PICTURE, 安正超提了問題xxxx 'action' => NEW, 'user_id' => 安正超ID, 'object_id' => 問題ID, 'object_user_id' => 安正超ID, 'object_type' => QUESTION 二級結構： 安正超評論了文章xxxx（回答了通用） 展示： 文章： xxxxx 評論：xxxxx (李林評論的) 'action' => COMMENT, 'user_id' => 安正超ID, 'object_id' => 評論ID, 'object_type' => COMMENT, 'object_user_id' => 安正超ID 'parent_object_id' => 文章ID, 'parent_object_user_id' => 作者ID 'parent_object_type' => ARTICLE, 三級結構： 安正超在文章中回復了李林的評論 展示： 文章： xxxxx 評論：xxxxx (李林評論的) 回復:xxxx (安正超) 'action' => REPLY, 'user_id' => 安正超ID, 'object_id' => 評論ID, 'object_type' => COMMENT, 'object_user_id' => 李林ID 'parent_object_id' => 文章ID, 'parent_object_user_id' => 作者ID 'parent_object_type' => ARTICLE, 'reply_id' => 安正超的回復ID 四級結構： 安正超回復了李文凱在問題 「xxxx」 中 李林的答案下的評論 說明：問題信息從答案介面取回 展示： 問題： xxxxx 答案1... 答案2... 答案3...(李林回答的) 評論：xxxxx (李文凱評論的) 回復:xxxx (安正超) 'action' => RESPOND, 'user_id' => 安正超ID, 'object_id' => 評論ID, 'object_type' => COMMENT, 'object_user_id' => 李文凱的ID 'parent_object_id' => 答案ID, 'parent_object_type' => ANSWER, 'parent_object_user_id' => 李林ID 'reply_id' => 安正超的回復ID
② 好友列表資料庫設計
3種解決方法，也談談這三種的弊端吧！
方法：
一.每創建一個用戶.自動創建一個該用戶的好友用戶表.每一行的記錄是一個好友記錄.
二.做一個Frient的表,表中有兩列,第一列UID是用戶ID,第二列FID是對應該用戶的好友
三,在用戶信息的表中,有一個欄位10000長度的varchar 里邊用','號分割各個好友的ID
弊端：
一：只適合少量的用戶論壇，如果有100萬個注冊用戶，就得有100萬張好友表，這樣當用戶一多，資料庫會很大！
二：這種方法是給用戶注冊表創建一張好友關聯表，這樣或許是這三種方法中最好的方式了吧，但是注意記得要添加索引，不然查詢起來，數據一多，會非常慢；
三、這樣在程序方面會比較麻煩，先取出來，後添加數據，再update，感覺速度會上不來...........
③ 開發一款社交APP需要哪些功能
1、基礎社交功能：評論、點贊、轉發、打賞、互相關注，聊天，發圖片、發文字等。
2、圈子社交功能：圈子以興趣為引導，沉澱內容，匯聚用戶。用戶可以在自己關注的圈子裡面發布興趣內容和其他用戶進行交流。
3、動態/朋友圈社交功能：滿足用戶碎片化時間，消息可快速傳播的方式。
4、短視頻社交功能：「短視頻+社交」模式在實踐中不斷改革並完善，短視頻為社交媒體貢獻很多原創內容和更強的用戶黏性；另一方面，社交平台為短視頻的快速傳播提供了渠道。
5、問答社交功能：幫助拉近人與人之間的距離，將持續產生高質量、可沉澱的信息，並讓有價值的信息和人都關聯起來。
6、活動社交功能：為消費者互動參與打造的活動，可匯集用戶，增強用戶黏性，拉新引流
7、資訊功能：用戶能及時地獲得資訊信息並利用它而能夠在相對短的時間內給自己帶來價值的信息。
可參考社交軟體系統thinksns，是比較成熟的系統
④ 怎麼開發一款社交APP
社交APP開發，主要分為定製開發和模板開發：
一、模板開發
APP模板開發的速度較快，開發價格從幾千塊到幾萬塊不等，與定製開發相比，開發時間快，價格也較低。
當然有利就有弊，APP模板開發出來的APP安全性很差。由於模板源代碼所有權歸App開發商所有，企業只有使用權，再加上一套模板可能被很多家企業使用，所以很難保證代碼安全性，極易被黑客攻擊造成信息泄露。
另外，模板APP很難個性化修改。模板類App都是固定的功能和代碼，很多APP甚至連前端的UI都不能修改。所以造成開發出來的APP用戶體驗極差。
二、定製開發
定製開發，就是開發公司按照客戶要求定製App的功能和界面。定製開發通常都有一套完整的流程，從用戶需求分析，到團隊組建，再到UI設計程序搭建，APP程序完成後的反復測試，再到最後的上線APP應用商店。都是有完整流程保障的。
因為牽扯到人工成本和開發周期，和市面上的模板App相比，企業定製App的費用要稍高一些，從幾萬到幾十萬不等。由於需要反復測試修改各項功能，開發時間也要稍長一些。
如果您是想開發一款擁有完備功能和完美用戶體驗的APP，還是要選擇靠譜的APP定製開發公司!
⑤ 想用IMSDK集成一個社交類的app，做的資料庫怎麼才能連上IMSDK的伺服器
熱心網友
環信的即時通訊雲最適合你的，Android、iOS、Web三大平台都支持。實現極其簡單，只需要3步。
第一步：在環信官網注冊獲得使用碼。
第二步：在環信官網下載sdk集成，加幾行代碼到App中，調試並修改ui等配置。
第三步：將擁有im功能的App上線，就ok了！ 加入IM就是這么簡單。
⑥ 聊天系統的好友列表資料庫如何設計
對於關系資料庫，可以設一個這樣的欄位，這個欄位里存放了李四的所有好友，每個好友以「，」分隔；
對於非關系資料庫，比如說健值資料庫，可以使用一個大型的HASH表來存放，李四的所有好友以一個鏈接的方式串起來
。
比如:
linker表示鏈接
hash(李四)=linker(王五、張三、黃光、李明)
⑦ 安卓app 用戶注冊資料庫怎麼設計
1、產品研發期——產品上線前 首先產品運營要搞清楚產品的定位以及目標用戶。產品定位和目標用戶決定了產品要解決什麼問題、產品的風格，同時會影響後續產品運營的策略。畢竟，產品往往只是解決一個固定人群的需求，而不是一個普遍存在的需求。弄清楚產品定位和目標用戶，運營應該參與到產品設計、開發的過程中，同時提供一些產品測試等支持。在這個階段，產品和運營應當配合的足夠默契，制定好符合產品的上線計劃。 另外，產品運營要做好必要的准備工作：上架渠道整理和賬號注冊、微信公眾號、微博、預熱方案製作和執行、產品上線活動方案。還有就是，如果是安卓渠道，大渠道的首發合作必須是要考慮的，例如：網路手機助手、360手機助手、應用寶等，都有新品首發。你必須先了解各大渠道的首發規則，並溝通預約好排期。新品首發可以帶來第一批自然增長的「種子用戶」，效果還是不錯的。 2、產品種子期——產品內測期 在這個階段，產品運營主要目的在於收集用戶行為數據和相關的問題反饋，和產品策劃一起分析討論進行產品優化。主要關注數據有：頁面路徑轉化，按鈕點擊，啟動次數，啟動時間段，停留時長等。這個階段數據量不求大，但求真實。而產品用戶的主要來源就是產品團隊邀請的身邊的人以及渠道首發的自然新增用戶。 這里必須要說明的是：種子期的運營工作不僅僅存在於這個階段，而是存在於產品每一個版本迭代的過程。 3、產品成長期——產品爆發期 產品本身性能以及體驗沒有問題以後，接下來就是產品開始大規模推廣的重要時機。推廣期主要目的在於擴大影響，吸收用戶。這個階段首先要做的就是鋪量，覆蓋各大渠道
⑧ 資料庫任務表結構設計 用於社交App 實現各種任務 比如：新手任務，成長任務 新手任務包括若干小
首先我不會，但是這點分不會有人幫你的這個很麻煩，我估計不會有人在這上面回復你有有的東西，你再等等看吧
⑨ 社交網路如何設計存儲好友關系的資料庫的
社交網路，他們都有，各自的資料庫來對你的，各個數據信息，來進行獨立的儲存，所以好友關系也是他們資料庫中的一條信息而已
⑩ 聊天軟體的資料庫設計
簡單的設計如下：如需其他功能，需要擴展，
用戶（主鍵，賬號，密碼，郵箱，..）
好友關系（所屬者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),
..
)