感測器數據的數據庫規範化
我正在開髮質量評估工具的後端。而且我達到了太多列的限制。
SQLSTATE
$$ HY000 $$:一般錯誤:1005 無法創建表
xxx
。xxx
(錯誤號:185“列太多”)因為我見過這個問題。讓我解釋:
我工作的公司正在銷售帶有韌體算法的高級感測器。對於每個新韌體,我們都希望將其與以前的韌體進行比較,以檢查某些東西是否仍然有效、是否有所改進或現在變得更糟。為此,我們有許多測試場景(200+)。每個場景都包含 (400-2.000) 個測量值,所有這些測量值都需要。我將一個場景的執行稱為記錄。
在我之前的設計中,我為每條記錄創建了一個表,最終得到了 50.000 多個表,至少可以說這不是最優的。為了規範數據,我創建了以下模式:
每個場景(
slug_1
和slug_2
這裡)都有桌面。idmap
以及將每條記錄與韌體和其他重要數據相關聯的表格(此處顯示為other_stuff
)。現在的問題是,在一種情況下,每次測量我需要 1-4 列,這意味著最多 8.000 列,這是一個新問題。除了
id
和表名之外,對這些大表沒有任何關係,也沒有搜尋要求。每個請求將包含來自同一個表的兩行以比較它們。問題:
- 是否有更好的設計來儲存數據?
我想也許我應該將測量值儲存為 json 字元串或將測量值數組直接序列化為二進制。我可以在儲存和讀取數據後解壓縮數據之前使用壓縮算法嗎?
- 如果它們從未被搜尋過,這麼多列是否還有那麼糟糕?
如果沒有,我該如何繞過
錯誤號:185“列太多”
編輯1:
回答一些問題:
- 是所有測試都通過/失敗,還是您需要儲存更多細節。
目前,每個測量值都包含兩個值。
Ok
(bool) 和Ct
(int)。Ok
僅儲存是否有錯誤。感測器可以提供約 10 個不同的錯誤,為什麼測試失敗,但我現在將其減少到true
/false
。如果需要儲存錯誤,我將創建一個錯誤表並儲存關係。第二個值Ct
儲存此測量所需的時間。將來可能會有 3. 值,但目前不需要。
- 細節的類型是否取決於測試?
不,並非在所有情況下測量都是相同的。
- 這些測試是否適用於產品或感測器?
是的,我將所有感測器、韌體和其他東西儲存在單獨的表中,
other_stuff
並將其與idmap
表關聯到測試場景的記錄。這裡有一些我正在使用的資訊:
Laravel 8 與php 雄辯的
mysql
數據庫。
- 是否有更好的設計來儲存數據?
大概。考慮到查詢約束(不搜尋測量數據,只檢索完整數據集),我決定將測量數據儲存在一個
json
欄位中。由 MySQL和Laravel支持。 2. 如果它們從未被搜尋過,這麼多列是否還有那麼糟糕?在這裡我仍然沒有一個具體的答案,但我可以說,無論引擎如何,都不可能在 MySQL 中儲存這麼多列。如果您使用
utf8
.$$ 1 $$
是否有更好的設計來儲存數據?
大概。測量似乎本身就是一個實體,應該像一個實體一樣建模。然後,您將需要場景和測量之間的一對多(或多對多,如果特定測量適用於多個場景)的關係。