【原因】
在資料庫效率測試的時候，乙個sql的執**況跟實際的應用場景有關，大部分在開發優先考慮正確性，再考慮效率問題。
在考慮效率問題上，由於時間原因導致無法一次性思考多個方面，而且隨著時間和應用的積累導致一系列的問題，而無法在本地重現問題原因，很盲目的找問題的所在，導致多次修改sql來觀察;更重要，你不可能在生產機上做問題分析~只能盡量在本地重現問題~
【模擬問題重現】
拋開其他比如iis壓力、硬體本身之類問題外，對於資料庫來說，模擬的就是寫入和讀取
【模擬引數】
1、每秒寫入資料多少條
大資料多少條，比如日誌，也許是2000位元組之上
常規資料多少條，比如相片位址，一般都是100個位元組
日誌資料多少條，這類資料資料不大，200位元組左右，但頻繁
2、每秒讀取資料多少次
注意，間隔時間的模擬
為了讓情況更真實些，要考慮一定的併發情況。
乙個時間刻度上，有多少個寫入請求，有多少個讀取請求
【模擬程式的要求】
1、有完善的引數設定
2、能儲存模擬的引數
3、有日誌記錄
4、盡量讓此程式能獨立，僅僅對外部僅僅呼叫，而非嵌入開發。實在不行，實現此部分的模組化，方便開發模擬情況的程式。
【達到的效果】
執行此軟體，能有效的在查詢分析器上，看出一些特定環境下的執**況，重現問題，以及更實時看除錯的sql的執行計畫。
爭取5月1號之前寫出此程式
/*2011-4-11*/
流程描述：
1、啟動主程式，進入引數設定和任務啟動介面
2、根據引數配置，啟動任務-
至於怎麼啟動任務，需要思考下如何走：
方案一：
建立乙個任務，這個任務自身不斷建立執行緒，實現資料庫寫入和讀取的任務
方案二：
建立乙個任務，以cmd命令方式啟動新的程式，此程式來實現執行緒的寫入和讀取資料庫
主程式控制啟動多少個新的程式，每乙個新程式都是在某時間段執行和結束，不會採用迴圈方式。
方案三：
建立乙個任務，以函式指標的方式執行執行函式，此函式實現執行緒的再次分配任務執行緒，這一級的執行緒才實現寫入和讀取資料庫。
優劣：方案一，耦合性太重，不宜擴充套件
方案二採用的程序+執行緒
方案三採用的執行緒+執行緒
後兩種的差距在一定程度上沒有什麼影響
個人建議採用方案三
先思考如何讀寫資料庫？
模擬資料庫類
include using namespace std 抽象類，相當與介面 class database 程式設計師使用資料開發 class program 資料庫廠商具體的訪問驅動 class oracle public database void query string sql class d...
MatrixCursor 模擬資料庫
原文 contentprovider對外共享資料的時候的query 方法是需要乙個cursor的，但是如果沒有資料庫，而專案又需要從contentprovider讀取資料的時候怎麼辦？更糟糕的是其他方法操作也都是需要cursor的。此時就需要matrixcursor了。相當有趣，它相當於為你模擬了乙...
C 資料庫讀取和寫入
下面為資料庫資料的讀取 using system.data.oledb string strdsn provider microsoft.jet.oledb.4.0 data source metest.mdb string strsql select from developer 例項化oledb...