首先在數(shù)據(jù)庫的選擇上，我們使用了SQL Server。在項目的開始階段，我們考慮過使用哪種數(shù)據(jù)庫，但很快就定下來了。使用SQL Server最大的原因是以前的項目就是用它，必須繼承下來。如果這是全新的項目，那估計選的還是SQL Server。如果用SQL Server跟MySQL去比的話，前者是商業(yè)性產(chǎn)品，估計會穩(wěn)定一點。我們對什么性能、大并發(fā)量這樣的需求是不強的，數(shù)據(jù)的安全和穩(wěn)定是最重要的。到了后面，上位機同時支持了SQLite。我們的上位機完成以后，我們發(fā)現(xiàn)，上位機的安裝不到10秒，而數(shù)據(jù)庫的安裝需要半個小時以上。我感覺這是有點本末倒置的。支持SQLite之后，要使用我們的上位機，安裝變得十分簡便。當(dāng)然，我們還不敢把SQLite的版本放在一些重要項目上。
上位機使用的數(shù)據(jù)表主要有三個。
（1）采集數(shù)據(jù)表。
（2）設(shè)備信息表。
（3）因子信息表。
設(shè)備信息表和因子信息表的設(shè)計并不難，內(nèi)容我們也已經(jīng)在上一節(jié)里討論，這里就不贅述了。
采集數(shù)據(jù)表是用來保存測量的數(shù)據(jù)的，設(shè)計要點有：
（1）數(shù)據(jù)一般是一分鐘保存一條，如果保存10年以上的話，就會有五百多萬條數(shù)據(jù)。
（2）查詢的時候，會查分鐘數(shù)據(jù)、小時數(shù)據(jù)、日數(shù)據(jù)、年數(shù)據(jù)等。
（3）每個站點的因子數(shù)量是不一樣的，有的只有十個不到的因子，有的有兩三百個因子。
（4）設(shè)備是經(jīng)常發(fā)生變化的，有時候增加一臺設(shè)備，有時候換掉一臺設(shè)備，采集數(shù)據(jù)表的表結(jié)構(gòu)需要動態(tài)變化。
根據(jù)上面的需求，我們做了這樣的設(shè)計：
（1）一個數(shù)據(jù)用兩列存儲，一個存數(shù)值，一個存狀態(tài)。在存數(shù)值的時候，我們用了float類型，因為采集到的數(shù)據(jù)都是這個類型。但是我們在統(tǒng)計的時候，還有存儲大整數(shù)的時候遇到了問題。所以還是建議用double去存儲數(shù)據(jù)。
（2）列有時候多，有時候少，但數(shù)據(jù)庫不能沒有一個規(guī)定的格式。我們把列數(shù)定為100，也就是最多存儲50個數(shù)據(jù)。如果超過了50，我們使用分頁的方法。例如第38個數(shù)據(jù)，它在第38列，第0頁。而第72個數(shù)據(jù)，它在第22列，第1頁。這種設(shè)計其實在查詢的時候是比較復(fù)雜的，性能也是比較差的。但超過50個數(shù)據(jù)的站點并不多。
（3）在因子信息表里面，記錄了某個因子對應(yīng)采集數(shù)據(jù)表里的第幾列。要查詢一個數(shù)據(jù)，必須結(jié)果因子信息表和采集數(shù)據(jù)表。
（4）當(dāng)設(shè)備、因子發(fā)生變化的時候，采集數(shù)據(jù)表里的數(shù)據(jù)不發(fā)生變化，只是因子信息表里的對應(yīng)關(guān)系發(fā)生改變。
在數(shù)據(jù)庫里加入頁的設(shè)計其實是不太好的，我們建議按照下面的設(shè)計：
（1）最初的列數(shù)是0，當(dāng)添加因子的時候，動態(tài)添加列。這樣的話，在首次改變結(jié)構(gòu)的時候可能會慢一點，但后面的查詢會變得簡單。
（2）列刪除了意味著數(shù)據(jù)就不見了，很多時候我們需要先把數(shù)據(jù)備份好再去刪除列。
