A. 新浪微博資料庫是如何設計的
這個問題的答案好像很復雜。可以看下新浪微博架構師TimYang的《構建高性能的微博系統——再談新浪微博架構》
談談個人看法：
微博技術架構的關鍵點在於如何優化Cache和消息隊列的使用效率，以及合理規劃數據存儲方式。
如此海量的數據推送必然是通過非同步消息隊列處理，而不是簡單的資料庫直接寫入，因此系統的負載壓力會逐層分散到後端資料庫上，並不是集中於某幾台資料庫上。
新數據通知，應該通過各種基礎服務預先計算出的數據集合，再通過客戶端每30秒的輪詢請求返回，並非請求後的實時計算，因此壓力可能更多的集中在cache層上。
B. 新浪微博「點贊功能」資料庫如何設計的
對於第一個問題，設計一個schema->(messageID，likedCount)，記錄每條微博的點贊數。messageID是微博的編號，likedCount是該微博的點贊人數。但是這里有兩個問題需要解決，第一是並發，第二是數據量。
每條微博都有可能有很多人同時點贊，為了保證點贊人數精確就需要保證likedCount++是原子操作，這個可以由應用程序來實現，也可以用redis的事務來實現(如果redis有事務機制或者自增功能的話)，但是我覺得為了性能考慮，也可以不用實現原子操作，具體原因就不展開了。
每天都上億可能更多的微博內容產生，這樣就會有上億個新的(messageID，likedCount)生成，這樣的數據量是比較大的，單機資料庫比較難提供高效的服務，所以需要採取sharding的功能(有時候也叫分表分庫)，可能根據messageID把這些schema分散到十個或者更多的shards上(據說，sina微博有600個節點，如何三個節點組成一個shard，就有200個shards)，這樣每個shard處理的請求就只有原來的十分之一，從而就能提高服務的性能。
關於點贊人列表的設計，一般來說，可能想到的schema是(messageID，userID)，但是這樣的設計有一個小問題，就是有些大發的微博可能會得到幾十萬的點贊，這樣就會產生幾十萬個條數據，這樣數據有點多，讀取起來可能也慢。所以可以用這樣一個schema(messageID，partID，userIDs)，讓一個messageID對於多個userID，同時比對應太多的userID，所以加入一個新的partID，一個part存1000個userID，這樣幾十萬個點贊，只需要存幾百條數據。這樣做還有一個好處，用戶點擊查看點贊人時的，一般都不是完全顯示所有點贊人，而是一批一批顯示，這樣可以一次只讀一條數據，就可顯示一批點贊用戶信息。
C. 微博 好友關注和推送功能的資料庫設計是怎麼實現的底層設計
我雖然沒參與過微博底層的開發，如果是我設計這個資料庫的話我會用2張表解決這個問題
第一張表 用戶信息表， 主要依靠ID主鍵識別用戶
第二張表，關系表， 關鍵col3列 前兩列 分別是 好友源 和 好友目標 ,第三列是 關系狀態
然後加了好友 只要不斷地 在第二張表加入 新行 比如
用戶A，用戶C ，好友
用戶A，用戶B ,黑名單
用戶B,用戶A, 好友
如果是QQ這類 檢索關系時候 0， 1欄位一起搜索ID 就是互為好友
微博這種 就是單向的 關注。
大概就是這樣的模型
可能的問題是用戶過多時候表2可能會非常巨大。檢索速度可能會受影響
用資源換效率的方式
還可以每個用戶一張表
D. 新浪微博的「關注功能」資料庫是如何設計的
你好。方法有二個：
我覺得是這樣設計的
一個欄位記錄他所關注的好友信息
應該是json的
然後去資料庫查最新的就是更新就是
uchome就是這么乾的
sql">--用戶表(如果這個表數據相當多，可以用分區表)
createtableuserinfo
(useridnumber(38,0),--可以用序列遞增值也成，自己看著辦
usernamevarchar2(60),
phonevarchar2(20),
addressvarchar2(20),
sexchar(1),
cdatedatedefaultsysdate
--其他欄位，自己添加
);
_userinfoprimarykey(userid);
--用戶關注信息表(如果這個表數據相當多，可以用分區表)：
createtableuserattention
(useridnumber(38,0),--用戶ID
attention_useridnumber(38,0),--被關注的用戶ID
statusnumber(18,0),--關注狀態(或者說關注等級，自己定義：0代表什麼，1代表什麼)
cdatedatedefaultsysdate,--創建時間
udatedatedefaultsysdate--修改時間
--其他欄位，自己添加
);
--為保持數據完整性：不管是「用戶ID」還是「被關注的用戶ID」其ID必須在userinfo表中存在！
_userattentionprimarykey(userid,attention_userid);
_userattention_useridforeignkey(userid)referencesuserinfo(userid);
_userattention_att_useridforeignkey(attention_userid)referencesuserinfo(userid);
userattention表中一個userid對應該可能有N條記錄(而不像你說的：用一條記錄，其不同的attention_userid用逗號隔開，這樣設置是不合理的)
--好比QQ號，我的QQ可以添加N個QQ好友，但我想：騰迅應該不會將我這N個QQ好友用字串連成一條記錄（這也太吝嗇啦）
E. 微博系統中粉絲數的增加是如何實現的要具體的資料庫表設計
關注@經典語錄online
F. 類似微薄的資料庫里的數據表是如何設計的
第一種：
通過對兩種語言寫的OA系統的比較,對這兩種語言的差異進行了一個全面的比較.
現在市場上的oa基本上可歸結為兩大陣營，即php陣營和java陣營。但對接觸oa不久的用戶來說，看到的往往只是它們的表相，只是明顯的價格差異，卻很難看出它們之間的實際差異。其實， PHP + MYSQL 不值錢不僅僅局限於oa軟體，而是整體上PHP + MYSQL開發的軟體都不如java開發的軟體值錢。為什麼PHP + MYSQL 的OA為什麼不值錢呢？首先得明白php和java之間的差異才行。
1、系統的技術架構比較
分層是將系統進行有效組織的方式，分而治之的思想是計算機領域中非常重要的思想。在好的分層思想引導下，便能實現「高內聚、低耦合」，也能將具體的問題割裂開來，易於控制、易於延展，更易於分配資源。PHP只能實現簡單的分布式兩層或三層的架構，而JAVA在這方面就十分強大，可以實現多層的網路架構。運用MVC的設計模式，可使oa系統具有更加高效、合理的系統架構。技術架構的落後，使運用php編寫的oa軟體系統先天不足，而後天又無法補足其先天上的劣勢。使得系統在可拓展性、需求應變性上與JAVA編寫的oa軟體系統的差距越來越大。架構的差距，註定了php做的oa充其量是個小家碧玉，始終無法和java這種大家閨秀同台競技。
2、資料庫訪問比較
PHP可編譯成具有與許多資料庫相連接的函數。將自己編寫外圍的函數去間接存取資料庫。通過這樣的途徑當更換使用的資料庫時，可以輕松地修改編碼以適應這樣的變化。但PHP提供的資料庫介面支持彼此不統一，比如對Oracle, MySQL，Sybase的介面，彼此都不一樣。由於PHP對於不同的資料庫採用不同的資料庫訪問介面，所以資料庫訪問代碼的通用性不強。
而Java通過JDBC來訪問資料庫，通過不同的資料庫廠商提供的資料庫驅動方便地訪問資料庫，訪問資料庫的介面比較統一。如果同樣是將開發的web應用從MYSQL數據數轉到ORACLE數據，PHP需要做大量的修改工作，而且比較繁瑣。但JAVA開發的便只需要很少的更改便能實現。
資料庫訪問方式的差異，奠定了php開發出的oa和java開發出來的oa是馬車和火車的差距，前者只能亦步亦趨而且額度有限，後者卻是工業化的結晶，不僅能夠包容萬物而且速度上穩步提升。
3、安全性對比
在同是開源和跨平台的java面前，php丟掉了很多的優勢。在代碼的安全性上尤為突出。php的開發程序在別人拿到代碼後，可以很容易的進行修改。而java開發的程序由於無法看到完整的源代碼，只能看到一些編譯好的類文件，所以安全性較高。加之系統架構的優勢，在安全性上php和java是相去甚遠。
如果非要將php和java在安全性上做個比較的話，同一個小偷光顧php那是隨便拿來隨便改，想拿什麼拿什麼，拿的高興還能大筆一輝某某到此一游。而光顧java的時候，便會發現警察把守，內設自動報警裝置，即便突破重重阻擾後進入居室。那值錢的東西都放在加密後的保險櫃中，只能望洋興嘆、鎩羽而歸。
4、前瞻性和拓展性
從整體來說，php適用於中小型系統，而java適用於大型系統。Php能夠將單一的事件做好，但卻不適合完成集成度較高的多項並發事件。為什麼說php適合中小型系統而不適合做大系統呢？
首先， php缺乏多層結構支持。而對於大型的系統負荷站點，只能採用分布計算。將資料庫、應用邏輯層和表示邏輯層彼此分開，並將同層的根據流量分開，組成二維數組。而php恰恰缺乏這種支持。
其次，PHP提供的資料庫介面不統一，要將多個不同的資料庫數據統一需要花費很大的力氣。而JAVA則沒有這種缺陷，可通過SUN Java的Java Class和EJB獲得規模支持，通過EJB/CORBA以及眾多廠商的Application Server獲得結構支持。如IBM的E－business，它的核心是採用JSP/Servlet的Web Sphere，是通過CGI來提供支持的。
如果將Php比作將才，具備獨擋一方的能力。那麼java便是帥才，具有較好的前瞻性和拓展性，整體布局和協同能力強。能夠指揮千軍萬馬，最後逐鹿中原。
5、開發成本比較
既然php在諸多方面都不如java優異，那麼php開發出的oa產品何以與java產品競爭呢？在於Php陣營普遍走的是低端路線，而java陣營走的是中高端路線。兩者之間交*的區域較小。
軟體價格的高低很大程度上和自身成本和功能相掛鉤。php的入門門檻較低，絕大多數學過c的程序員都很容易轉型為php程序員，這使得php程序員的泛濫成災的同時，低成本的php軟體產品也層出不窮。以PHP最經典的組合PHP + MySQL + Apache為例，由於所有軟體都是開源免費的，所以投入並不高。
而java開發需要特定的環境，成長為一個合格的java程序員需要一定的時間，java程序員的成本也是php成本的幾倍。Java的web應用伺服器免費的有Tomcat、JBoss等，而要想具有很好的商業化服務便必須選用Web Sphere和 Web logic。這其中投入的成本無形中便超是php成本的N倍。所以，java開發oa的成本要遠遠高於php開發出來的同類軟體產品。但也正由於java開發的成本較高，很難實現抄襲和短期內逾越的可能，也使得java用開發出的產品門檻更高。
不怕不識貨，就怕貨比貨。Php開發出來的產品也能用，但是和java開出的同類產品是沒法比較的。正因為php開發的產品整體性能和java開發的相去甚遠，所以php運用低成本的低價優勢和同類的java產品抗爭，以價格落差來平衡購買者的心態。所以，PHP + MYSQL 的OA不值錢也就不足為怪了
第二種
比較PHP和JSP這兩個web開發技術，在目前的情況是其實是比較PHP和Java的Web開發。以下是我就幾個主要方面進行的比較：
一、 語言比較
Php是解釋執行的伺服器腳本語言，首先php有簡單容易上手的特點。語法和c語言比較象，所以學過c語言的程序員可以很快的熟悉php的開發。而java需要先學好java的語法和熟悉一些核心的類庫，懂得面向對象的程序設計方法。所以java不如php好學。
Java首先要編譯成位元組碼.class文件，然後在java虛擬機上解釋執行。Java的web開發首先最容易想到的就是JSP（現在已經到JSP2.0），原來的java的web開發都是用servlet來實現的，用servlet來開發需要程序員在java的源文件中嵌入大量的html代碼。所以後來就出現了JSP,JSP可以方便的嵌入到html文件當中，其實jsp文件在伺服器上執行的時候首先會被應用伺服器轉換成servlet，然後再編譯執行。Jsp可以通過servlet和JavaBean的支持產生強大的功能。JavaBean 是一種可復用的、跨平台的軟體組件。使用javabean可以方便的實現java代碼和html的分離，能夠增強系統的功能和軟體的復用性。
Java的web開發屬於SUN公司定義的J2EE其中的規范。而且在J2EE中包括了java的web開發的所有方面，如：JSP、Servlet、JDBC、JNDI、JAVABEAN、EJB等等。J2EE就特別適合於做大型的企業級的應用。
二、 資料庫訪問比較
Java通過JDBC來訪問資料庫，通過不同的資料庫廠商提供的資料庫驅動方便地訪問資料庫。訪問資料庫的介面比較統一。
PHP對於不同的資料庫採用不同的資料庫訪問介面，所以資料庫訪問代碼的通用性不強。例如：用Java開發的web應用從MySQL資料庫轉到Oracle資料庫只需要做很少的修改。而PHP則需要做大量的修改工作。
三、 系統設計架構比較
採用Java的web開發技術，需要使用的是面向對象的系統設計方法，而PHP還是採用面向過程的開發方法。所以用Java進行開發前期需要做大量的系統分析和設計的工作。
四、 跨平台性
Java和PHP都有很好的跨平台的特性。幾乎都可以在不作任何修改的情況下運行在Linux或者Windows等不同的操作系統上。
五、 開發成本比較
PHP最經典的組合就是：PHP + MySQL + Apache。非常適合開發中小型的web應用，開發的速度比較快。而且所有的軟體都是開源免費的，可以減少投入。
Java的web應用伺服器有免費Tomcat、JBoss等，如果需要更好的商業化的服務有：Web Sphere和 Web logic。
六、 分布式多層架構比較
PHP只能實現簡單的分布式兩層或三層的架構，而JAVA在這方面就比較強大，可以實現多層的網路架構。資料庫層（持久化層）、應用（業務）邏輯層、表示邏輯層彼此分開，而且現在不同的層都已經有一些成熟的開發框架的支持。例如Struts就是利用java的web開發技術實現了MVC的設計模式，而在業務邏輯層也有Spring框架，資料庫持久化層有Hibernate等框架。這些框架可以方便開發者高效、合理、科學得架構多層的商業應用。
下面簡要的說一下Struts，它實質上是在JSP Model2的基礎上實現的一個MVC（Model、View、Controler）框架。JSP Model2體系結構是一種聯合使用JSP 與Servlet 來提供動態內容的方法。在Struts框架中，模型由實現業務邏輯的JavaBean或EJB組件構成，控制器由Servlet實現的，視圖由一組JSP文件組成。採用Struts可以明確角色的定義和開發者與網頁設計者的分工。而且項目越復雜，其優勢越明顯。
七、 源代碼安全
PHP開發的程序的源代碼都是公開的，他人拿到php開發的程序後都可以進行修改。
Java開發的程序，最後用戶拿到的是只是一些編譯好的class類，無法看到完整的源代碼，安全性高。
八、性能比較
有人做過試驗，對這兩種種語言分別做迴圈性能測試及存取Oracle資料庫測試。
在循環性能測試中，JSP只用了令人吃驚的四秒鍾就結束了20000＊20000的迴圈。而PHP測試的是2000＊2000循環（少一個數量級），卻分別用了63秒。
資料庫測試中，二者分別對 Oracle 8 進行 1000 次 Insert,Update,Select和Delete： JSP 需要 13 秒，PHP 需要 69 秒。
表格 1 PHP 與Java的比較
PHP JAVA
可復用性 低 高
開發速度 快 慢
易維護性 差 優
可移植性 優－Linux、Windows、Unix等
安全性 低高
開發費用 低 高
多層架構 差 優
資料庫訪問 介面不統一 介面統一
可擴展性 差 優
面向對象 差 優
綜上所述，我個人認為，PHP適合於快速開發，中小型應用系統，開發成本低，能夠對變動的需求作出快速的反應。而Java適合於開發大型的應用系統，應用的前景比較廣闊，系統易維護、可復用性較好。還有，同樣功能的系統用Java開發的系統要比PHP開發的系統的價格要高.
G. 微博的關注和被關注功能資料庫怎麼設計比較好
剛剛特意去看了下discuzX2.5的收聽關系數據表 所有收聽關系數據是數組形式的 然後轉換成字元串都存放在pre_common_member_field_home表具體可以參考下
H. 網站接入微博和qq登錄資料庫表怎麼設計最佳
你好。方法有二個：
我覺得是這樣設計的
一個欄位記錄他所關注的好友信息
應該是json的
然後去資料庫查最新的就是更新就是
uchome就是這么乾的
-- 用戶表(如果這個表數據相當多，可以用分區表)
create table userinfo
( userid number(38,0), -- 可以用序列遞增值也成，自己看著辦
username varchar2(60),
phone varchar2(20),
address varchar2(20),
sex char(1),
cdate date default sysdate
-- 其他欄位，自己添加
);
alter table userinfo add constraints pk_userinfo primary key(userid);
-- 用戶關注信息表(如果這個表數據相當多，可以用分區表)：
create table userattention
( userid number(38,0), -- 用戶ID
attention_userid number(38,0), -- 被關注的用戶ID
status number(18,0), -- 關注狀態(或者說關注等級，自己定義：0代表什麼，1代表什麼)
cdate date default sysdate, -- 創建時間
udate date default sysdate -- 修改時間
-- 其他欄位，自己添加
);
-- 為保持數據完整性：不管是「用戶ID」還是「被關注的用戶ID」其ID必須在userinfo表中存在！
alter table userattention add constraints pk_userattention primary key(userid,attention_userid);
alter table userattention add constraints fk_userattention_userid foreign key (userid) references userinfo(userid);
I. SNS,微博 好友關注和推送功能的資料庫設計是怎麼實現的底層設計
用戶離線了是沒法通知的，因此沒必要通知所有關注的人。一個大v可能被很多人關注，但是關注的人就不會很多，1000很多了吧，1萬應該是機器人了吧。因此每個用戶在線的時候去讀取有沒有推送信息更簡單。
J. 微博資料庫設計
看用什麼語言寫，用php+mysql比較合適，
sql資料庫
應該學過吧！這個學過的話在網上下載一個開源的記事狗微博（
http://www.jishigou.net/）
，模仿他的
資料庫設計
，微博涉及的資料庫很簡單，寫過留言板的都可以弄，就是許可權系統會復雜點！