1

我正在开发一种医疗软件，我的目标是将大量自定义操作存储到数据库中。因为跟踪谁做了什么非常重要，所以每次用户做一些有意义的事情（例如写评论、添加一些医疗信息等）时都会产生一个动作。现在的问题是随着时间的推移会有很多动作，假设每个患者有 10000 个，可能有 50000 个患者，总共有 5 亿个动作（甚至更多）。

当前数据库模型看起来像这样：

[Patient] 1 -- 1 [ActionBlob]

因此，每个患者都只有一个大 blob，其中包含所有动作作为大序列化字节数组。当然，当表变大时，这将不起作用，因为我必须一直在数据库和客户端之间来回传输整个字节数组。

我的下一个想法是列出单独序列化的动作（不是大块），即

[Patient] 1 -- * [Action]

但我开始怀疑这是否是一个好方法。现在，当我添加新动作时，我不必序列化所有其他动作并将它们传输到数据库，而只需序列化一个动作并将其添加到 Actions 表中。但是加载数据怎么样，因为一张表可能有 5 亿行，它会超慢吗？

所以基本上问题是：

  1. sql server 可以处理从 5 亿行的表中加载 10000 行吗？（这些数字可能更大）
  2. 实体框架可以处理 10000 个实体的具体化而不会很慢吗？
4

2 回答 2

1

问题 1 和 2 的简短回答：是的。

但是，如果您要一次性完成这些“物化”，您宁愿使用 SqlBulkCopy。我建议您查看以下内容：

关于您的模型，您绝对不应该使用 blob 来存储操作。有一个包含 Patient 外键的 Action 表，并确保在该表中有一个时间戳列。这样，当您必须为给定患者加载操作时，您可以使用时间作为过滤条件（例如，加载最近 2 个月的操作）。

由于您可能要获取给定患者的操作，因此请确保将患者 FK 设置为索引。

希望这可以帮助。

问候， 卡里尔

于 2012-06-27T06:58:27.107 回答
1

您的第二个想法是正确的，对于 SQL 数据库来说，拥有较小的百万项不是问题，而且如果您在操作表中索引一些有用的列，它将导致更快的性能。

将操作存储为 blob 是一个非常糟糕的主意，因为每次您都必须从 blob 转换为单个记录以进行搜索，并且它不会提供搜索等的任何好处。

对于 SQL 服务器来说，正确索引的十亿条记录根本不是问题。

在没有用户界面的情况下，我们会一次看到数百万条记录，我们总是会分页记录，例如 1 到 99、100 到 199 等等。

我们有近 1000 万行的表，但一切都很顺利，因为经常搜索的列被索引，外键被索引。

于 2012-06-27T07:03:12.080 回答