PDFファイルをバイナリオブジェクトとしてSQL Serverに保存しますか、そうですか？
次のタスクの設計上の決定を見つける必要があります。
SQL Serverデータベースがあり、注文のテーブルが含まれています。 PDFドキュメントは、Webページからの単純なファイルアップロードを通じてユーザーによってアップロードされ、注文に割り当てられます。注文ごとに1つのドキュメントしかありません（おそらくドキュメントはなく、1つしかありません）。この目的のために、ユーザーはWebページを開き、注文番号を入力し、表示された注文を取得して、アップロードボタンをクリックします。そのため、アップロードされたドキュメントがどの順序に属しているかがわかります。
現在、ドキュメントをWebサーバーに保存するための2つのオプションを検討しています。
1）varbinary（MAX）列で注文のテーブルを拡張し、PDFドキュメントをそのバイナリフィールドに直接保存します。
2）PDFファイルをディスク上の特定のフォルダーに保存し、注文に関連する一意の名前を付けます（たとえば、データベースの主キーである注文番号、またはGUID注文テーブルの追加の列に格納できます）。おそらく、ファイルを1か月に1つ、サブフォルダーに保存し、サブフォルダー名をデータベースの注文行に保存して、1つのフォルダーに何千ものファイルが入りすぎないようにする必要があります。
PDFファイルが保存されたら、関連する注文番号を入力した後、ブラウザからダウンロードして表示できます。
私はオプション（1）の傾向があります。1つのデータベースにすべての関連データがあると、データ管理が簡単になるからです。しかし、データベースのサイズがソリューション（2）の場合よりもはるかに速く増大するため、時間の経過とともにパフォーマンスの問題が発生する可能性があることを少し心配しています。データベースサイズ全体の約90％または95％は、保存されているPDFファイルのみで構成されます。
追加情報は次のとおりです。
- PDFファイルのサイズは、それぞれ約100キロバイトです。
- 1か月あたり約1500注文/ PDFファイル
- Windows Server 2008 R2/IIS 7.5
- SQL Server 2008 SP1 Express
- ハードウェアについてはよくわかりませんが、QuadCore Procは1つだと思います。および4 GBのRAM
- アプリケーションはASP.NET Webforms 3.5 SP1で記述されています
（私は上記の数値で約2年後にSQL Server Expressエディションの4GBの制限に達することを認識しています。しかし、ここではこれを無視できます。データベースから古いデータを削除するか、フルライセンスにアップグレードすることは可能なオプション。）
私の質問は次のとおりです。オプションの賛否両論は何ですか、そしてあなたは何をお勧めしますか？おそらく誰かが同様のタスクを持っていて、彼の経験について報告することができます。
よろしくお願いします！
関連：
SQL Server 2008では、サイズがほとんど1 MB以上のドキュメントがある場合、FILESTREAM機能が推奨されます。これは、Microsoft Researchによって公開された BLOBへまたはBLOBへではない と呼ばれる論文に基づいています。
平均で256K未満のドキュメントの場合、VARBINARY(MAX)列に格納するのが最適です。
その間のすべては、実際には少しトスアップです。
PDFほぼ100K前後のドキュメントが存在することになります->それらはSQL Serverテーブルに非常に適切に格納されます。問題ありません。考慮すべき1つのことは、別のテーブルを持つことです。メインのファクトテーブルにリンクされているドキュメントの場合、ファクトテーブルの使用が速くなり、ドキュメントが他のデータの邪魔になりません。
これは画像の保存について何度も尋ねられましたが、それらについての議論はまだ当てはまります：
また、ドキュメント用に別のテーブルを作成します。これにより、ドキュメント取得用の検索データ/キーフィールドをよりキャッシュ可能にします。データベースがドキュメントテーブルにアクセスする必要があるのは、挿入時またはダウンロード時のみです。
SQLでファイルを保存することをお勧めします。ファイルを取得するときにオーバーヘッドが追加されます。 IISはファイルを提供するのに非常に効率的ですが、SQLはストレージ機能であるため、WebサーバーからSQL Serverにホップして戻る必要があるため、ボトルネックが生じました。ファイルを取得します。
ファイルをウェブサーバーに保存すると、プロセスはリストされた基準に基づいて適切なファイルを決定し、それをポイントして提供できます。 DocumentumやAlfrescoなどのドキュメント管理システムは、共有にファイルを保存します。これにより、バックアップおよび冗長ストレージに関する柔軟性が大幅に向上します。
原則として、私たちは同様の状況に遭遇しました。 SharePointに保存されたドキュメントにWebページのリンクからアクセスできる方法が必要でした。すべてが固有のプロジェクト番号を持つプロジェクトベースであるため、解決策は、ドキュメントに共通の命名規則を実装することでした。 ■Webページがサーバー側で作成され、リンクが動的に作成されます。コードはSharePointサーバーへの基本パスを取得し、プロジェクト番号とドキュメントの詳細を追加します。
例：
[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]
私はSQLに大きなblobを格納することに懐疑的です。SQLページサイズが4k（ナットから外れている）であると想定しています。ファイルをユーザーに提供するときに、ファイル全体のフラグメントをnKブロックにアセンブルする必要があります。かどうかはそうです。