1

私は医療ソフトウェアに取り組んでおり、私の目標はデータベースに多くのカスタム アクションを保存することです。誰が何をしたかを追跡することは非常に重要であるため、ユーザーが何か意味のあることを行うたびにアクションが生成されます (コメントを書く、医療情報を追加するなど)。ここでの問題は、時間の経過とともに多くのアクションが発生することです。たとえば、患者ごとに 10000 としましょう。50000 人の患者がいると、合計で 5 億 (またはそれ以上) のアクションが発生する可能性があります。

現在、データベース モデルは次のようになっています。

[Patient] 1 -- 1 [ActionBlob]

したがって、すべての患者は、すべてのアクションを大きなシリアル化されたバイト配列として含む 1 つの大きなブロブを持っているだけです。もちろん、データベースとクライアントの間で常にバイト配列全体をやり取りする必要があるため、テーブルが大きくなるとこれは機能しません。

私の次のアイデアは、個別にシリアル化されたアクションのリストを (大きなチャンクとしてではなく) 持つことでした。

[Patient] 1 -- * [Action]

しかし、これが良いアプローチかどうか疑問に思い始めました。新しいアクションを追加するときに、他のすべてのアクションをシリアル化してデータベースに転送する必要はありませんが、1 つのアクションをシリアル化して Actions テーブルに追加するだけです。しかし、データのロードについてはどうですか? 1 つのテーブルに 5 億行ある可能性があるため、超低速になるでしょうか?

したがって、基本的に質問は次のとおりです。

  1. SQL Server は、5 億行のテーブルから 10000 行の読み込みを処理できますか? (これらの数値はさらに大きくなる可能性があります)
  2. エンティティ フレームワークは、非常に遅くならずに 10000 個のエンティティの実体化を処理できますか?
4

2 に答える 2

1

質問1と2の簡単な答え：はい。

ただし、これらの「具体化」を1回の操作で行う場合は、SqlBulkCopyを使用することをお勧めします。以下をご覧になることをお勧めします。

モデルについては、アクションを格納するためにBLOBを使用しないでください。患者の外部キーを持つアクションテーブルを用意し、このテーブルにタイムスタンプ列があることを確認してください。このように、特定の患者のアクションをロードする必要があるときはいつでも、フィルタリング基準として時間を使用できます（たとえば、過去2か月のアクションをロードします）。

特定の患者のアクションを取得する可能性が高いため、必ず患者FKをインデックスとして設定してください。

お役に立てれば。

よろしく、カリル

于 2012-06-27T06:58:27.107 に答える
1

2 番目のアイデアは正しいです。100 万個のアイテムを小さくしても問題はありません。また、アクション テーブルでいくつかの有用な列にインデックスを付けると、パフォーマンスが向上します。

アクションを blob として保存することは非常に悪い考えです。検索するたびに blob から個々のレコードに変換する必要があり、検索などの利点が得られないためです。

適切にインデックス化された数十億のレコードは、SQL サーバーにとってまったく問題ではありません。

また、1 から 99、100 から 199 などのように、常に 100 万件のレコードを一度に表示するユーザー インターフェイスはありません。

1,000 万行近くのテーブルがありますが、頻繁に検索される列にはインデックスが付けられ、外部キーにはインデックスが付けられているため、すべてがスムーズです。

于 2012-06-27T07:03:12.080 に答える