一个网站的诞生- MagicDict开发总结2 [ACCESS的烦恼]
??? 說到數據庫，有很多很多選擇，除了MS-SQL，Oracle，SQLite，MySql，這些大家都非常熟悉的同學，還有DB2，IMSDB（灰常灰常古老的數據庫，用在OS390等Mainframe中，層次型數據結構，不做大型機的同學們可能不知道）。不過，大部分個人網站的首選還是Access，理由很簡單，ASPNET的空間，它是免費使用的。
???? 天下沒有白吃的午飯，ACCESS對于小型數據庫來說，完全沒有什么問題，不過，如果數據庫非常龐大的話，呵呵，可能讓你整天提心吊膽了。（特別是對于入門級的網絡空間來說，簡直就是災難）
???? 好了，來說說我的故事吧。我和ACCESS，不得不說的故事。
??? 使用數據庫，第一件事情，就是數據庫的設計，不過，具體設計不在這篇文章里面介紹了。[數據庫的設計，其實是非常令人糾結的事情，特別是ACCESS這種弱小的東西，考慮到空間服務商1%CPU使用率的規定，有的時候要努力的優化，不然，訪問很慢很慢很慢]。第二件事情就是使用數據庫。
?? 使用數據庫，都是從建立DBConnection開始的。如何建立DBConnection，無非是通過一個數據庫連接字符串New出一個數據庫連接實例。數據庫連接字符串放在什么地方，我很負責任的說，有N種地方可以放這個東西。最最簡單的，直接寫死在數據庫訪問類里面：
OleDbConnection?rtnConnection?=?new?OleDbConnection();rtnConnection?=?new?OleDbConnection("大家好，我是數據庫連接字符串");
當然，同學們在各種模式設計和IOC的洗腦下，都知道要把這個寫在配置里面了。其實在小的項目，這個真的沒有什么實際的意義。為了Install B，為了展示我也是學習過高手的代碼的，我也這樣寫了。[大型項目，非常有必要這么做，通過配置文件來修改數據庫，不是通過改寫代碼來修改數據庫]
1。先把字符串寫在配置文件里面，
??<appSettings>????<add?key="strconForJpDic"?value="Provider=Microsoft.Jet.OLEDB.4.0;Data?Source=@urlbase\Kuww_Net_System\Access\TJJTDS.mdb;Persist?Security?Info=True"/>
??</appSettings>
2。通過配置管理器ConfigurationManager獲得配置文件里面的字符串內容，然后實例化OleDbConnection
????????OleDbConnection?rtnConnection?=?new?OleDbConnection();rtnConnection?=?new?OleDbConnection(ConfigurationManager.AppSettings["strconForMagicDict"].Replace("@urlbase",?UrlBase));
3。接下來就是打開數據庫連接。
??? 這里有一個問題，我一直不是很明白。數據庫連接并不是要顯式Open才能使用。有時候不寫Open，Close也可以使用。
??? 一說，數據庫組件會自動打開，一說，有數據庫連接緩存池，這個問題我始終不知道為什么。
??? 另外，如果數據庫一直開著，不知道是不是有什么問題。
????數據庫連接開開關關，是不是會有性能問題呢？高手有人知道嗎？
?
下面是這個故事的重點了：
??? 數據庫的話，原來我只做了一個Access文件，這里面有查詢要用的一些表格，這些表格是單純Selete的。
??? 同時為了記錄下沒有查詢到結果的詞語，這里還有一個用于數據記錄INSERT的表格。
??? 這個數據庫的大小為13M，應該不是很大的數據庫。放在網絡上測試一下，第一次，不錯，速度很快，第二次，也可以，不過，到了第N次后，網站整體速度就不行了。為什么速度會不行呢，如何解決這個問題呢？為了提高網站速度，我使用了很多方法，這個將在以后的文章里面介紹。最后發現，數據庫不給力，是最大的兇手。怎么辦？怎么辦？“花錢買SQL空間可能會提高速度”，空間服務商的同學給出了一個很好[很標準]的答案，當然，也是促銷的方法。我心里也明白，這個方法一勞永逸了，不過，我喜歡在苛刻環境中，壓榨系統的最后一滴油。。。。（不是圖省錢，和CPU超頻的朋友一樣，能夠壓榨系統，也是一種樂趣）。
??? 數據庫的問題，可能是因為數據庫的占用空間太大了，在數據庫無法壓縮的情況下面，有什么好辦法嗎？把一個數據庫拆成2個試試看吧。這個方法的根據是，一次操作針對一個大數據庫可能會很慢，化整為零可能會好一點。在1個時間單位里面處理1個大數據庫，可能會對CPU造成瞬間的大的負荷，如果把處理分在2個時間單位里面，CPU使用會相對平緩，在查詢時間不是很苛刻的時候，這個會很管用。同時，把檢索的表和插入的表格分在不同數據庫里面，這樣，需要讀的文件大小不變，需要寫的文件就變得小了很多，IO的負擔也降下來了。
???把數據庫一分為二后，上線，測試一下，OK，世界重新變得美好了。。。。
?? [后來繼續試驗發現，兩個數據庫，只讀和讀寫分開來是關鍵，單個數據庫大小并不是很重要。現在13M的數據庫被分割為11M只讀和2M讀寫，并沒有平均分割，保證讀寫的那個足夠小，才是王道。有大蝦能夠解釋一下理由嗎？]
?
總結一下：
??? 1。數據庫會拖累網站速度
??? 2。數據庫只讀和讀寫表格，在使用ACCESS的時候，最好能分開來，保證每次寫文件使用的IO盡量少。
?
?
另外，覺得一個人做網站太苦了，有人愿意加入網站開發嗎？日語單詞檢索網站，ASPNET開發的。
有興趣的寫信給我 root#magicdict.com?? [convert # to @ ]
或者加MSN mynightelfplayer@hotmail.com
網站地址 http://www.magicdict.com/
?
?
?? ?
???
轉載于:https://www.cnblogs.com/TextEditor/archive/2011/05/29/2061031.html
總結
以上是生活随笔為你收集整理的一个网站的诞生- MagicDict开发总结2 [ACCESS的烦恼]的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Windows Phone 7.1 “芒
- 下一篇： netflix数据处理2(转)