次のように、SQL Server 2005のvarbinary（max）列にバイナリファイルを保存する必要があります。
FileInfoは、FileContentと1対1の関係にあります。FileTextは、アップロードするファイルがなく、アイテムに対してテキストのみが手動で入力される場合に使用されます。アイテムの何パーセントがバイナリファイルを持つかわかりません。
2番目のテーブルを作成する必要があります。2つのテーブルの設計でパフォーマンスが向上するでしょうか。論理的なメリットはありますか？
このページを見つけましたが、私の場合に当てはまるかどうかはわかりません。
パフォーマンスや運用上の利点はありません。SQL 2005以降、LOBタイプは、エンジンによって別のアロケーションユニット（別のBツリー）にすでに保存されています。SQL Serverのテーブルとインデックスの構成を調べると、すべてのパーティションに最大3つの割り当てユニット（データ、LOB、および行オーバーフロー）があることがわかります。
（ソース：s-msft.com）
LOBフィールド（varchar（max）、nvarchar（max）、varbinary（max）、XML、CLR UDT、および非推奨のタイプtext、ntext、image）は、データレコード自体に、クラスター化インデックスに、フットプリントが非常に小さい：LOBアロケーションユニットへのポインタ。レコードの解剖学を参照してください。
LOBを別のテーブルに明示的に格納することにより、何も得られません。以前のアトミック更新は2つの別々のテーブルに分散する必要があるため、不要な複雑さを追加するだけで、アプリケーションとアプリケーショントランザクション構造が複雑になります。
LOBコンテンツがファイル全体である場合は、SQL2008へのアップグレードとFILESTREAMの使用を検討する必要があります。
この2つのテーブルの設計には、論理的な利点はありません。関係は1対1であるため、すべての情報がFileInfoテーブルにバンドルされている可能性があります。ただし、特にバイナリデータのサイズが平均で数百バイトを超える場合は、運用上およびパフォーマンス上の重大な利点があります。
編集：Remus Rusanuが指摘しているように、SQL2005などの一部のDBMS実装では、ラージオブジェクトタイプは個別のテーブルに透過的に格納され、ビッグレコードを持つことの実際的な欠点を効果的に軽減します。この機能の導入により、[真の]単一テーブルアプローチの弱点が暗黙的に確認されます。
この質問で参照されているSO投稿をスキャンしただけです。私は一般的に、他の投稿は本質的なデータの整合性などのいくつかの有効なポイントを作成しますが（特定のアイテムに対するすべてのCRUDアクションはアトミックであるため）、全体として、比較的非定型のユースケース（アイテムの使用など）を除いてテーブルは、ほとんどの場合一度に1つのアイテムに対してクエリされるリポジトリとして使用されます）、パフォーマンス上の利点は、2つのテーブルのアプローチによるものです（これにより、「ヘッダー」テーブルのインデックスがより効率的になり、バイナリデータを必要としないクエリがはるかに迅速に返されます。 。など）
また、2つのテーブルのアプローチには、異なるコンテキストで異なるタイプのバイナリオブジェクトを提供するように設計が進化した場合に、さらに利点があります。たとえば、これらのアイテムが画像（GIF、JPGなど）であるとします。後日、これらの画像の小さなプレビューバージョン（および/または高解像度バージョン）も提供する必要があります。この選択は、コンテキスト（ユーザー設定、低帯域幅クライアント、サブスクライバーとビジター）によって決まります。等。）。このような場合、単一テーブルアプローチに関連する運用上の問題がより深刻になるだけでなく、モデルはより用途が広くなります。
純粋にSQLServerのいくつかの制限のために、IMAGE、（N）TEXT、（N）VARCHAR（max）、およびVARBINARY（max）列をより広いテーブルから分離するのに役立ちます。
たとえば、2012年以前は、LOBが含まれている場合、クラスター化されたテーブルをオンラインで再構築することはできませんでした。一方、これらの制限については気にしないかもしれないので、データが関連しているようにテーブルを設定することをお勧めします。
LOBデータをテーブルアロケーションユニットから物理的に除外したい場合でも、「行外の大きな値タイプ」テーブルオプションを設定できます。
