我有一個數據庫，用於存儲來自各種儀器的溫度記錄數據。數據可能會每分鐘記錄一次。設計日誌表的一種方法是將每個日誌條目與設備ID，時間戳和序列號一起放入其自己的行中（即使設備上的時鐘發生改變，也應該可以對條目進行排序按照實際測量的順序）。然而，這看起來效率非常低，因爲除了系統爲索引添加的內容之外，每個16位測量都可能附帶16個字節的其他數據。我認識到，試圖優化數據庫中的每個最後一個字節通常是毫無意義的，但將數據擴展到9：1或更差似乎很愚蠢。用於頻繁記錄小物體的高效數據庫設計
目前，我將記錄彙總到等距讀數組中，並以變長不透明二進制格式存儲每個記錄的一組，以及第一次讀數的設備ID，時間戳和序列號，以及閱讀間隔。這很好，我知道的可能是最好的方法，但它不允許太多的查詢方式。
有沒有什麼好辦法處理這樣的數據集沒有過多的冗餘？
您的數據不會擴大9倍。您的數據保持大致相同，因爲您沒有開始的16位測量。您的測量結果是在特定時刻從特定設備進行的第N次測量。所以你的數據確實有有一個序列號，一個設備ID和一個時間戳，甚至在你將它們添加到數據庫之前，無論你是否願意考慮它。
如果將數據存儲在關係表（SQL）中，請將其存儲爲關係格式：標準化。每行一個記錄。以可查詢的格式存儲信息。以不透明的二進制格式「彙總」記錄會使整個數據庫無用，因爲數據無法查詢，彙總，過濾，甚至無法執行。你對'這個很好地工作'的定義基本上是'我可以寫數據，沒有人可以使用它'，這很不好'。您也可以將數據轉儲到/dev/nul ...
將數據存儲爲正確的記錄。將數據存儲爲適當的數據庫類型，請勿使用「不透明斑點」。任何數據庫標準都不會「頻繁」地記錄「每分鐘記錄一次的數據」。如果你說'每秒100次'，那麼我們就有話要談。
@Remus Rusanu：在數據進入數據庫之前，它通過記錄測量設備來保存數據。這些設備將數據存儲在多達32次測量的打包記錄中;設備ID和下一個記錄序列號只需要在設備中保存一次，並且時間戳和記錄頻率僅在每個記錄的設備中存儲一次。單獨查看記錄時，元數據是「真實數據」，但在查看連續記錄時，集合中的實際數據量遠遠小於孤立查看的記錄總量。 – supercat 2010-09-05 18:54:28
@Remus Rusanu：有保證每個記錄不超過一天的數據可以彙總。因此可以通過在感興趣的時間前一天開始搜索來查找給定間隔的所有記錄。其他所需類型的查詢將是在一個時間間隔內找到最小和最大溫度;這可以通過在記錄中添加最小和最大溫度的字段來協助;記錄在感興趣區間的開始或結束的一天內將不得不被解析，但中央部分中的記錄可以原樣使用。 – supercat 2010-09-05 18:58:39
@supercat：*爲什麼*你將數據存儲在*數據庫*中？ – 2010-09-05 21:02:02
我相信你應該使用RRDtool來存儲這樣的數據。 Wikipedia article。
儘管我沒有在要求中提到它，但記錄頻率可能會發生變化，並且在發生這種情況時可能需要保留歷史數據。 – supercat 2010-09-05 18:55:51
這真的是個問題嗎？想象一下，我們高估了一點，並說每個測量有50個字節的數據+元數據。 Google表明你不會有很多問題，除非你處於一個非常緊張的環境中。
這是什麼平臺？ – 2010-09-05 16:19:42
目前的方法有什麼問題嗎？每分鐘記錄1條記錄的頻率不足以花時間優化，除非您處於嚴重受限的環境中，或者沒有更好的辦法。不成熟的優化是萬惡之源。 – 2010-09-05 16:23:29
如果最終用戶安裝了該數據庫，則數據庫將爲SQL Server 2005，否則爲MS Access。數據來自小型嵌入式處理器，這些處理器在包含時間戳，測量間隔和一個或多個測量（測量通常每天收集一次）的打包記錄中將數據傳送到PC。測量數據可能需要保存多年。 – supercat 2010-09-05 19:00:32