0

我有一个桌面应用程序，它具有一个名为Field.

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

Fields 是由用户定义的，因此用户可以根据需要设置任意多个。它们与另一个名为 的实体相关联Employee。

Fields 对于一年中的每一天都有一个值（由应用程序计算和存储的 16 位整数）。

Field值存储在一个表中，其中每条记录都保存了一整年的值Employeeone Field。

因此，该表看起来有点像这样：

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

FieldValues 将值作为字节数组保存在 BLOB 字段中，然后将其转换回 16 位整数数组，然后在网格上显示给用户。

现在我们有了一些背景，真正的问题。

这是一个遗留应用程序，我不是原始设计师。不过，很容易猜到，以二进制格式存储这些数据的目的是限制记录的数量，否则每年Employee每个Field.

我现在正在做的是一个“同步”应用程序，它从本地 Access 数据库中提取这些数据（不要问），并通过 REST API 将其推送到远程服务器上的 Web 应用程序。这样的应用程序需要有这个数据的副本，所以我必须将它存储在它的数据库中。

以二进制格式存储数据的明显优势是真正限制了我们需要存储的记录数量，但缺点是人类不可读。

另一方面，Web 应用程序是多租户的，因此以任何其他方式存储这些数据都意味着存储大量记录：仅仅几千Employee秒，平均 20Field秒意味着存储超过 1400 万条记录年（并且Fields不是唯一可以生成数百万条记录的实体）。另外，如果在未来的某个地方，比如说每两三年，我们可以把它们扔掉，那么每年的大量记录本身就不是问题；然而，事实并非如此。

那么，真正的问题是如何存储所述数据。我应该坚持旧格式吗？

谁能想到一种完全不同的方式来解决它？

为了完整起见，尽管我认为这并不重要，但目标数据库是 Postgres。

4

1 回答 1

1

如果可能的话，您应该正确规范化这些数据。

这里有一些原因。

以二进制格式存储数据的明显优势是真正限制了我们需要存储的记录数量，但缺点是人类不可读。

您还缺少其他缺点，包括增加的并发性，因为您必须将所有值写回。对这些数据的查询都不会是 SARGable，你不能在 db 级别上限制这些数据，基本上是你违反 1NF 时遇到的所有问题

另外，如果在未来的某个地方，比如说每两三年，我们可以把它们扔掉，那么每年的大量记录本身就不是问题；然而，事实并非如此。

我想不出你不能制定数据保留政策的正当理由。这样做非常危险。

另一方面，Web 应用程序是多租户的，因此以任何其他方式存储这些数据将意味着存储大量记录：仅几千个员工和平均 20 个字段将意味着每个存储超过 1400 万条记录年

这不是很多记录。通常，您存储的数据量往往首先成为问题。其中大部分被FieldValues中的数据占用，而不是数据库必须做的内部簿记。

于 2013-06-18T15:34:22.217 回答