我正在研究医疗软件，我的目标是将大量自定义操作存储到数据库中。由于跟踪谁做了什么是非常重要的，每次用户做有意义的事情时都会产生一个动作（例如写评论，添加一些医疗信息等）。现在的问题是，随着时间的推移会有批次的行动，让每位患者说10000，而且可能有50000名患者，导致总共5亿次行动（甚至更多）
目前数据库模型看起来像这样：
[Patient] 1 -- 1 [ActionBlob]
因此，每个患者只需要一个包含所有动作的大blob作为大的序列化字节数组。当然，当表变大时，这不会起作用，因为我必须在数据库和客户端之间来回传输整个字节数组。
我的下一个想法是列出单独序列化的动作（不是一个大块），即
[Patient] 1 -- * [Action]
但我开始怀疑这是不是一个好方法。现在，当我添加新操作时，我不必序列化所有其他操作并将它们传输到数据库，只需序列化一个操作并将其添加到Actions表中。但是加载数据怎么样呢，因为一个表中可能有5亿行，所以它会超流吗？
基本上问题是：
答案 0 :(得分：1)
对问题1和问题2的简短回答：是的。
但是，如果你在一次移动中进行这些“实现”，那么你宁愿使用SqlBulkCopy。 我建议你看看以下内容：
关于您的模型，您绝对不应该使用blob来存储Actions。有一个具有Patient外键的Action表，并确保在此表中有一个时间戳列。 这样，每当您必须为给定患者加载操作时，您可以使用时间作为过滤条件（例如，加载过去2个月的操作）。
由于您可能要为给定患者获取操作，请务必将患者FK设置为索引。
希望这有帮助。
此致 Calil
答案 1 :(得分：1)
你的第二个想法是正确的，拥有数百万个项目对于SQL数据库来说不是问题，如果你在动作表中索引一些有用的列，它将导致更快的性能。
将操作存储为blob是一个非常糟糕的想法，因为每次您必须从blob转换为单个记录到搜索，它不会提供任何搜索等好处。
正确索引的十亿条记录对SQL服务器来说根本不是问题。
在没有用户界面的情况下，我们一次会看到百万条记录，我们将始终记录1到99,100到199等记录。
我们有几乎1000万行的表，但一切都很顺利，因为经常搜索的列被索引，外键被索引。