方法2：用xml型別代替主從表設計，從而達到提高查詢效能。
優化和提高資料庫的效能，是從乙個良好的資料庫設計開始的。以乙個會議預訂系統為例，乙個預訂會議系統包括了會議時間，會議地點，主持人，參與人，知會人，記錄者等相關資訊。在的tdd，ddd模型主導的時代，在這兒為了更好的想表達我要闡述的問題，還是以表驅動模型來進行開發。
使用者需求：
a：乙個會議可能有多個主持人，雖然這種情況比較少，但是也有可能有。
b：乙個會議有多個參與人，這個不難理解。
c：乙個會議有可能要讓某人知曉，這人可以參與或不參與會議，一般為高層。
d：乙個會議有可能有零個或者多個記錄者。
f：會議預訂成功，或者會議時間，會議地點等重要資訊修改後，郵件通知與會人員。
常規資料庫設計：
a：建乙個meeting的主表，用於存放會議名稱，會議地點，會議時間等的相關資訊。
b：再建乙個meetinguser的表儲存主持人，參與人，知會人，記錄者。
c：同樣，會議所需要的裝置用meetingdevice表來儲存相關的資訊。如圖：
這樣的表結構，是比較常規的設計方法，但是在實際應用中，你會發現一些待改進的問題。比如：
a：在提取乙個會議的相關資訊時，會連線多個表進行查詢。這種查詢在很大的程式上影響了資料庫效能。
b：在做修改操作時也夠嗆的，先修改主表的相關資訊，再把主表關聯的子表資訊全部刪除重新插入一次，這樣的操作是否夠**了。當然有人精益求精，會比較修改前和修改後的資料，再用增加，刪除，修改的手段達到子表資料的更新。這樣的操作在有些orm操作中已經實現了，但當自己code**來實現的時候，特別是在多次code的時候，感覺總是那麼煩心。
吐槽了這麼多，是否有更好的解決方案呢？當然，在sql裡，我們可以xml資料型別來消除主從表的設計。如圖：
上面的表結構設計，是不是有乙個小清新的感覺呢？很明顯，可以把第一種表的設計缺陷給消除了。乙個會議的相關資訊都儲存在了乙個表的一條記錄中，這樣的資料看起來是不是更直觀呢？
a：獲取乙個預訂會議的詳細資訊，我不需要進行多個表的連線查詢，我要做的是只需用c#的linq.xml來解析查詢出來的xml字串即可。
b：修改操作時，我只需要重新組合xml資料，乙個update就更新了與會議相關的資訊，操作是不是簡單多了。
表面上看這種設計已經完美了，但是使用者的需求是無止境的，有一天，你收到了乙個需求，查詢某個使用者參與過的所有會議（就是只要主持人，參與人，或者記錄者中包括了這個使用者，就把這些記錄都給查詢出來），oh！my god 這種表結構設計應該怎麼解決這個問題呢？其實可以用xquery解決這個問題，還沒接觸過xquery的那得趕快充一下電了。xquery中最常用的有 exist(),value()這些函式，這兒就不詳細的介紹了，網上搜尋一下有很多相關資料，如果有必要，我會把以前專案中用的xquery技巧與大家分享。
MySQL批量插入千萬級別的資料
使用mysql插入千萬級別的資料，如果使用單條的插入，在時間效能上肯定會讓人懷疑人生。這裡為了學習，收集了網上幾個對於mysql插入大資料量的部落格，以便自己後面的學習。1 mysql批量插入資料庫實現語句效能分析 2 mysql千萬級別資料批量插入只需簡單三步 3 關於批量插入資料之我見 100萬...
如何設計一張千萬級別的大表
1 資料的容量 1 3年內會大概多少條資料，每條資料大概多少位元組 2 資料項 是否有大字段，那些欄位的值是否經常被更新 3 資料查詢sql條件 哪些資料項的列名稱經常出現在where group by order by子句中等 4 資料更新類sql條件 有多少列經常出現update或delete ...
ZCMS的Web採集 一 千萬級別的網路爬蟲
zcms的網頁採集功能介面簡潔，但功能強大，共由五部分組成 一 乙個大容量的頁面檔案容器。1.2 該容器能通過url快速訪問檔案 類似於hashmap 1.3 該容器支援壓縮存放。1.4 該容器將頁面的概要資訊和內容分開存放。1.5 該容器的訪問效能不隨訪問檔案數量的增長有大的變化。2.1 完全支援...