SQL Azure/SQL Serverは、異なるスキーマで機能する可能性が高くなります。効果的には、提案されたデザインで大規模なBLOBを1日中読み書きしているため、より最適な論理的および物理的なデータベース設計パターンと比較して、パフォーマンスがIO上でボトルネックになる可能性があります。 （言い換えれば、コードファーストのテクニックを実行するのは、コード化するのが速く、この場合は実行が遅くなります）。
私はあなたがおそらくあなたがいるとは異なる、この問題にアプローチしたい警告を最初に基本的な質問に答えることをしようとします
：
日時：Nテーブル対1のテーブル：SQL ServerとSQL Azureのクエリプランを作成してキャッシュします。これらのプランのコンパイルは高価な場合があります。そのため、SQLのコンパイルオーバーヘッドを減らすために、同じスキーマを持つテーブルの数を減らすのが一般的です。 （JSON BLOB以外のスキーマは実際には作成していませんし、BLOBの読み込みと書き込みのオーバーヘッドは、アプリケーションでも解決するまでは最適化されていない可能性が高いです）。
Re：1000テーブル対1ビッグテーブル：適切なインデックス作成が行われていると仮定すると、SQLには発汗のない何十億行もの行を含む顧客照会パターンのテーブルがあります。だから、コンパイルのオーバーヘッドのために1000のテーブルが必要ないのですが、IO（論理的または物理的）を避けるのに十分な特定のものをクエリがすべて検索するようにして、アプリケーションのパフォーマンスが最適/近くになるようにします。
再：複数のテーブルからEF +ロード：私はEFの専門家（私はSQLの専門家で）午前ませんが、私はこの問題を離れて今1 + 2
に私の答えを与え行くと信じて私はあなたの問題をより効率的に解決する方法のガイダンスを提供しようとします。 SQL Azureでパフォーマンスを犠牲にするため、データベースの予約サイズを小さくすることで、コストを削減できます。
試すことができる主なパターンは2つあります。これらは、開いているスキーマか固定されたスキーマかによって少し異なります。顧客がそのJSON BLOB（オープン・スキーマ）で任意の値を作成できるようにする場合は、プロパティ・バッグまたはEAV（Entity Attribute Value）パターンを考慮する必要があります。これは、次のようになります。 CREATE TABLE EAV（CustomerID bigint、Attribute nvarchar（100）、Value sqlvariant） 次に、customerid属性にクラスタード・インデックスを作成するとします。
このパターンを使用すると、インデックスシークを使用して特定の値を読み取り、すべてを読み取る必要がある場合は顧客の属性全体をスキャンできます。これらの値は大まかにディスク上に配置され、更新はデータのIOだけを行い、ユーザーがタッチする属性のサブセットのログは更新します。 （NVarchar（max）は部分書き込みをサポートしていますが、最も簡単に実装する方法を推測しなければならない場合は、毎回BLOB全体を読み書きする予定です）。
N個の更新ステートメントを書き出す必要があるため、または更新する行セットを含む大きなものを一度に書き出す必要があるため、EAVパターンはすぐには簡単ではありません。
既知の列のセットがある場合は、それぞれの列を含む表を作成する方がよいでしょう。 （SQLには、ほとんどNULLの列に使用できる「疎な」列属性もあります）。これにより、必要に応じて各フィールドにインデックスを付けることができ、より複雑なアプリケーション（get-putアプリを超える）がうまく実行できるようになります。したがって、火曜日にあって特定の金額を上回る顧客の売上を検索する場合、このスキーマパターンでは、bツリーインデックスが使用されていると仮定して、それらのクエリをうまく実行させるインデックスモデルを使用できます。
SQL Server/SQL Azureもテーブルのパーティション化をサポートしています。非常に大きなテーブルの場合、パーティショニングを使用すると管理上のメリットが得られます。しかし、このようなアプリケーションを適切に索引付けしておけば、すべてが索引シークになる可能性があるので、メインライン・データ・アクセスのパフォーマンスを高速にする必要はありません。
希望に役立ちます！ Conor Cunningham アーキテクト、SQLコアエンジン
この種のデータモデルでは、リレーショナル（MSSQL）はおそらく適切なプラットフォームではありません。おそらく、HDInsightのほうが良いでしょう。しかしリレーショナルに戻ると、テーブルを物理的に分割すると、テーブルの物理的な名前を決めるのではなく、WHEREでデータにアクセスできるという利点があります。個々のテーブルを使用することの欠点は、新しい顧客が到着したときに新しいテーブルについて知る必要があるシステムを構築するための開発および保守オーバーヘッドです。保守と開発の複雑さは大きな影響を与えます –
1：データモデルの顧客IDの親は何ですか？例えば、顧客は、組織やグループに参加するなど、何らかの方法で関係しています。 2：また、顧客オブジェクトは、販売日のようにオブジェクトが時間の経過とともに期限切れになることを意味する自然なデータ値を持ちます。 3：既存のデータモデルは、従来のSQLデータベースではなく、SQLベースのデータベースやDocumentベースのデータベースのように見えます。これらの非伝統的なSQL Serverの使用例のために設計されたAzureおよびAWSなどの他の非SQLサーバーサービスもあります。 –
@SqlSurfer "顧客"は実際には組織です。各人間のユーザは、特定の組織の一部です。各ユーザーはオブジェクトを読み書きするため、データベースの「顧客」である組織のコンテキスト内でオブジェクトを読み書きします。これはB2Bサービスです。 2.古くなったオブジェクトをアーカイブする計画がありますが、作業セットは約5,000〜7,000万と推定されています。 3. NoSQLデータベースが検討されましたが、それ以外にも多くの従来のデータストレージが存在するため、そのように動作するのであれば、MSSQLにすべて保存しておくことが最善です。 – user1142433