22

次のタスクの設計上の決定を見つける必要があります。

SQL Serverデータベースがあり、注文の表が含まれています。PDFドキュメントは、Webページからの簡単なファイルアップロードを通じてユーザーによってアップロードされ、注文に割り当てられます。注文ごとに複数のドキュメントはありません（おそらくドキュメントはなく、複数はありません）。この目的のために、ユーザーは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
  • ハードウェアについてはよくわかりませんが、QuadCoreProcが1つあると思います。および4GBRAM
  • アプリケーションはASP.NETWebforms3.5SP1で記述されています

（上記の数値で約2年後にSQL Server Expressエディションの4GBの制限に達することを認識しています。ただし、ここではこれを無視できます。データベースから古いデータを削除するか、フルライセンスにアップグレードする必要があります。可能なオプション。）

私の質問は：オプションの長所と短所は何ですか、そしてあなたは何をお勧めしますか？おそらく誰かが同様の仕事をしていて、彼の経験について報告することができます。

よろしくお願いします！

関連している：

DBに画像を保存する-そうですか、それともそうですか？

4

6 に答える 6

27

SQL Server 2008では、ほとんどの場合1 MB以上のサイズのドキュメントがある場合は、FILESTREAM機能をお勧めします。これは、MicrosoftResearchが発行したToBLOBまたはnotto BLOBという論文に基づいており、データベースにBLOBを長期間保存することの長所と短所を分析しました。

平均で256K未満のドキュメントの場合、それらをVARBINARY(MAX)列に格納するのが最適のようです。

本当に、その間にあるものは少しトスアップです。

あなたはあなたがほとんど100KかそこらのPDF文書を持っていると言います->それらはSQLServerテーブルに非常にうまく保存されます、問題ありません。検討したいことの1つは、メインファクトテーブルにリンクされているドキュメント用に別のテーブルを用意することです。そうすれば、ファクトテーブルの使用が速くなり、ドキュメントが他のデータの邪魔になりません。

于 2010-02-27T15:33:05.073 に答える
1

また、ドキュメント用に別のテーブルを作成します。これにより、ドキュメント検索用の検索データ/キーフィールドがよりキャッシュ可能になります。データベースがドキュメントテーブルにアクセスする必要があるのは、挿入またはダウンロード中のみです。

于 2010-02-27T15:40:58.707 に答える
1

SQLにファイルを保存することはお勧めしません。ファイルを取得するときに余分なオーバーヘッドを追加しています。IISはファイルの提供に非常に効率的ですが、SQLを使用すると、WebサーバーからSQL Serverにホップしてファイルを取得する必要があるため、ボトルネックが導入されました。

ファイルをWebサーバーに保存すると、プロセスは、リストされた基準に基づいて適切なファイルを決定し、それをポイントして提供することができます。DocumentumやAlfrescoなどのドキュメント管理システムはファイルを共有に保存します。これにより、バックアップと冗長ストレージに関して大きな柔軟性が得られます。

于 2010-02-27T15:46:37.127 に答える
0

SQLページサイズが4k（ナットから外れている）であると仮定して、SQLに大きなblobを格納することに懐疑的です。ファイルをユーザーに提供するときに、ファイル全体のフラグメントをnKブロックにアセンブルする必要があります。そうであるかどうか。

于 2010-02-27T16:02:46.953 に答える
0

原則としては、同様の状況に遭遇しました。SharePointに保存されているドキュメントにWebページ上のリンクを介してアクセスできる方法が必要でした。すべてが一意のプロジェクト番号を持つプロジェクトベースであるため、解決策は、ドキュメントに共通の命名規則を実装することでした。■Webページはサーバー側で作成され、リンクは動的に作成されます。コードはSharePointサーバーへの基本パスを取得し、ドキュメントのプロジェクト番号と詳細を追加します。

例：

[SharePoint Base Path][Project Numbe][Project Document Name]
[http://mysharepoint.mycompany.com/213990/213990_PC.pdf]
于 2013-02-12T00:08:01.297 に答える