一個或多個 SQLite 表中多個源的時間序列數據？文件大小影響？

情況如下：

• 來自非常有限的一組來源的大量時間序列數據將保存在 SQLite 數據庫文件中。
• 時間序列源由 10 個字元長的字元串標識。來源的數量非常少，而且根本不是動態的。
• 時間序列源之間無需立即進行任何相關性分析。

我想，按照慣例，人們會將所有時間序列數據轉儲到一個表中，並帶有一個標識每個數據點來源的文本欄位。

但是，我想知道為每個時間序列數據源創建一個單獨的表是否更有效？通過消除重複的文本欄位，SQLite 數據庫的文件大小最終會變得更小嗎？查詢會執行得更快嗎？

或者我應該完全避免為每個來源創建一個表，出於什麼原因？

數據庫不會很大，這可能保證使用 SQLite 而不是 MySQL。除了整數時間戳之外，還有四個整數欄位。每 3 分鐘進行一次測量，但它可以輕鬆執行一年或更長時間。部分設計可能最終出現在具有非常有限數量的快閃記憶體（64Mbit）的嵌入式設備中，因此我最初對 SQLite 感興趣。但是，我願意接受其他建議。

就個人而言，我討厭丟棄可能有用的數據。我會為源創建一個表，並包含source_id在時間序列表中作為源表的外鍵。這應該佔用更少的空間，但仍然保留源資訊（不需要多個相同的表）。

我整理了一個簡短的例子；看到這個db-fiddle 連結。

這是我的範例的程式碼：

CREATE TABLE source
    ( source_id INTEGER PRIMARY KEY ASC
     ,name varchar(10)
    );

CREATE TABLE time_series
    ( series_id INTEGER PRIMARY KEY ASC
     ,timestamp INTEGER
     ,value1 INTEGER
     ,value2 INTEGER
     ,value3 INTEGER
     ,source_id INT
     ,FOREIGN KEY (source_id) REFERENCES source(source_id)
    );

INSERT INTO source (name)
VALUES ('AAAA'), ('BBBB'), ('QZQZ');

INSERT INTO time_series (timestamp, value1, value2, value3, source_id)
VALUES (12345678, 100, 105, 110, 1)
     ,(12345681, 105, 105, 105, 1)
     ,(12345684, 110, 105, 100, 1)
     ,(12345678, 9, 27, 81, 3)
     ,(12345681, 27, 81, 243, 3)
     ,(12345684, 81, 243, 729, 3)
;



SELECT * FROM source;

SELECT s.name as source, timestamp, value1, value2, value3
 FROM source s INNER JOIN time_series ts ON (s.source_id = ts.source_id)
ORDER BY source, timestamp
;

我應該注意我通常不使用 SQLite。正如您在回复我的原始評論時指出的那樣，預設情況下，SQLite 在每個表中維護一個 64 位整數行 ID 列。我在範例中設置了表，以使用該行 ID 值作為每個表的主鍵。如果我正確閱讀了文件，則外鍵列應該足夠大以保存主鍵中的值。假設您不手動插入一個source_id很大的，我相信source_id在time_series表中應該只需要 1 個字節。

您可能想在and上放置一個UNIQUE索引（您幾乎可以肯定在它們上有某種索引）；據推測，您永遠不應該有兩個條目用於同一來源和同一時間。正如 Serge Stroobandt 所指出的，這甚至可能是主鍵。但是，由於 SQLite 無論如何都會創建一個唯一的行 ID 值，所以我傾向於將其作為鍵。如果您真的想使用and作為主鍵，請查看創建表。source_id``timestamp``source_id``timestamp``WITHOUT ROWID

引用自：https://dba.stackexchange.com/questions/183316