舉一個例子,我現(xiàn)在有一些新聞信息,它包括這些字段;新聞ID,新聞Name,新聞ShortIntro,新聞Detail,新聞PublishTime。我現(xiàn)在要把它存放在數(shù)據(jù)庫中,然后從數(shù)據(jù)庫中將其取出來放在GridView中分頁顯示。
我現(xiàn)在就以一種我所見過的常見的思維方式來一步一步模擬這個實(shí)現(xiàn)過程。
第一步:建立新聞數(shù)據(jù)表。
在這一步,很多人都會直接建一張News表,里面包括了上面說的那些字段。
第二步:查詢數(shù)據(jù)。
寫一個方法,把News表中滿足查詢條件的數(shù)據(jù)取出來放在DataSet(DataTable)中,作為數(shù)據(jù)源。
第三步:綁定到GridView。
設(shè)置GridView的分頁屬性,將上面查詢得到的數(shù)據(jù)源綁定到GridView,實(shí)現(xiàn)數(shù)據(jù)在GridView中的分頁顯示。
上面就是我們常見的做法了。
我的做法會是這樣:
第一步:建立新聞數(shù)據(jù)主-從表。
我們在系統(tǒng)開發(fā)過程中會發(fā)現(xiàn),其實(shí)在一條的完整的數(shù)據(jù)信息中,其實(shí)很多時候,很多列表項并不會用到。我們分析News信息,我們可以初步的把ID,Name,ShortIntro,PublishTime作為主要信息,我們將這些信息集中起來,新建一張表News(ID,Name,ShortIntro,PublishTime),另外一個字段Detail放在另一張從表中,新建一張表NewsDetail(ID,Detail,NewsID)。這樣做有什么好處呢,首先我們降低了表的“重量”。我們將最重要,最常用的信息簡化出來放在一個主表中,這樣在使用過程中,我們只需要從這張住表中獲取我們所需的數(shù)據(jù)就可以了,而不需要像第一種方法一樣遍歷所有字段,這減少了數(shù)據(jù)庫查詢的時間,提高了性能。主-從表建立的原則是,將最重要的,最常用的分離出來作為主表,將那些描述性的,內(nèi)容龐大的作為從表。
第二步:編寫適合的SQL語句。
我們應(yīng)該為不同的功能實(shí)現(xiàn)編寫適合的SQL語句。上面那種方法中,用一個方法查詢出了所有的數(shù)據(jù)信息,這是滿足所有場合的數(shù)據(jù)要求的。但是,我們并不需要這么多的數(shù)據(jù)內(nèi)容,多余的數(shù)據(jù)內(nèi)容耗費(fèi)了我們大量的時間和空間。我們往往只需要其中的部分內(nèi)容,比如說主要信息。這也印證了為什么我們上面要建立主-從表。我們在建立了主-從表之后,為滿足各種場合,可以編寫以下幾種方法:GetNews(int? ID, string Name)//從主表中查詢滿足條件的數(shù)據(jù),GetNewsDetail(int? ID, string Name)//從主表和從表中查詢滿足條件的數(shù)據(jù)。第一種方法提供了新聞主要信息,第二種方法提供了全面的信息,這兩種方法基本上就能滿足所有場景且不會帶來過多的數(shù)據(jù)冗余。這里還要指出一點(diǎn),有些人喜歡這么寫GetNewsByID(int? ID ),GetNewsByName(string Name),這樣寫是很靈活,很有針對性,但是這樣寫完全沒必要。
第三步:分頁綁定。
上面那種方法是一次性取出所有數(shù)據(jù)給GridView,讓控件自己去分頁,這樣做方便省事。但是會有幾個問題:
(1)數(shù)據(jù)量大。因為是一次性取出所有滿足條件的數(shù)據(jù),所以數(shù)據(jù)量比較大,而這些數(shù)據(jù)是都需要放在內(nèi)存中的,所以會影響系統(tǒng)性能。而且在初次載入時會有些卡,給人的感覺是系統(tǒng)加載不平順。
(2)我們并不需要這么多數(shù)據(jù)。為什么我要這么說呢?研究用戶的使用習(xí)慣我們會發(fā)現(xiàn),用戶大多數(shù)情況下并不會逐頁的去瀏覽數(shù)據(jù),用戶關(guān)注的往往是前幾頁的前幾條。所以取出來的數(shù)據(jù)很多時候并沒有被用戶查看。
所以在這里,使用分頁查詢的方式是更加合適的。每次只從數(shù)據(jù)庫里面查詢一頁數(shù)據(jù),這樣系統(tǒng)負(fù)載小,頁面載入平順,而且完全能夠滿足用戶的使用要求。有些人會問,你這樣做不是會增加數(shù)據(jù)庫IO次數(shù),我想說的是,一次性獲取大量冗余數(shù)據(jù),并要承擔(dān)冗余所帶來的持久影響與這些比理論上增加的IO次數(shù)(用戶并不會逐頁查看,也就并不會產(chǎn)生那么多次分頁查詢)要小得多的訪問相比,分頁查詢具有不可否定的優(yōu)勢。
您可能感興趣的文章:- mysql數(shù)據(jù)庫查詢優(yōu)化 mysql效率
- 海量數(shù)據(jù)庫的查詢優(yōu)化及分頁算法方案
- 優(yōu)化MySQL數(shù)據(jù)庫中的查詢語句詳解
- 海量數(shù)據(jù)庫的查詢優(yōu)化及分頁算法方案集合1/2
- 海量數(shù)據(jù)庫的查詢優(yōu)化及分頁算法方案集合2/2
- 數(shù)據(jù)庫查詢優(yōu)化之子查詢優(yōu)化
- 一次數(shù)據(jù)庫查詢超時優(yōu)化問題的實(shí)戰(zhàn)記錄