數據存儲格式：字節數組的替代？

Question

我有一個桌面應用程序，它具有名爲Field的實體的概念。

----------------------- 
| Id | FieldName | 
----------------------- 
| 1 | "Field 1" | 
----------------------- 
| 2 | "Field 2" | 
----------------------- 

Field S通過用戶定義的，所以有可能是因爲其中許多爲用戶想要的。它們與稱爲Employee的另一個實體相關聯。

Field s對於每年的每一天都有一個值（由應用程序計算並存儲的16位整數）。

Field值存儲在每個記錄保存值的一個Field之一Employee整整一年的表。

所述表，因此，看起來有點像這樣：

--------------------------------------------- 
| FieldId | EmployeeId | FieldValues | Year | 
--------------------------------------------- 
| 1 |  4  | byte[] | 2012 | 
--------------------------------------------- 
| 2 |  4  | byte[] | 2012 | 
--------------------------------------------- 
| 1 |  5  | byte[] | 2013 | 
--------------------------------------------- 
| ... |  ... |  ...  | ... | 
--------------------------------------------- 

FieldValues保持值作爲BLOB字段一個字節數組，然後將其轉換回16位整數數組是前向網格上的用戶顯示。

現在我們已經有了一些背景，真正的問題。

這是一個傳統的應用程序，我不是原始設計師。然而，很容易猜到，以二進制格式存儲這些數據的目標是限制每Field每Employee每年存儲365（或366）值所需的記錄數量。

我現在正在做的是一個「同步」應用程序，它從本地Access數據庫（不問）提取數據並通過REST API將其推送到遠程服務器上的Web應用程序。 這樣的應用程序需要有這些數據的副本，所以我必須將其存儲在其數據庫中。

以二進制格式存儲數據具有確實限制我們需要存儲的記錄數量的明顯優勢，但是存在人爲不可讀的缺點。另一方面，網絡應用程序是多租戶的，因此以任何其他方式存儲此數據將意味着存儲大量記錄：僅僅幾千個Employee秒，而平均20個將會意味着存儲每年超過1400萬條記錄（並且Fields不是唯一可以產生數百萬條記錄的實體）。另外，如果每一年的大部分記錄都不會成爲一個問題，比如說每兩三年我們就可以扔掉它們;但是，情況並非如此。

真正的問題是如何來存儲所述數據。我應該堅持舊格式嗎？

任何人都可以想到一個完全不同的方式去實現它嗎？

爲了完整起見，即使我認爲它不重要，目標數據庫是Postgres。

Answer 1

您應該儘可能正確地規範化這些數據。

這裏有一些原因。

以二進制格式存儲數據具有真正 限制，我們需要存儲的記錄數量明顯優勢，但缺點被人類不可讀 。

還有其他缺點，包括增加的併發性，因爲你必須寫回所有的值。對這些數據的查詢都不會是SARGable的，你不能在db級別限制這些數據，基本上你違反1NF時遇到的所有問題基本上所有你遇到的問題你違反1NF

另外，大量的記錄per-如果在某個地方，比如說每兩三年，我們可以把它們扔掉;如果在某個地方，每年都不會有問題，例如 。但是，情況並非如此。

我想不出爲什麼你不能擁有數據保留策略的正當理由。這樣做非常危險。

在另一方面，Web應用程序是多租戶，因此存儲這些數據 以其他任何方式將意味着存儲的記錄大量：只是一個 幾千員工和平均20場將意思是 每年存儲超過1400萬條記錄

這不是很多記錄。通常情況下，您存儲的數據量往往首先成爲問題。其中大部分由FieldValues中的數據佔用，而不是數據庫必須執行的內部簿記。