一般に、ファイルシステムとは対照的に、データベース（具体的にはmssql）にファイルを保存することはパフォーマンスへの影響がどれほど悪いですか？アプリケーションの移植性以外に、ファイルをSQLServerに変数として保存したいという理由を思い付くことができません。
回答:
この答えを見てください：
基本的に、ユーザー数によっては、スペースとパフォーマンスの低下が非常に大きくなる可能性があります。また、Webサーバーは安価であり、負荷を分散するために簡単に追加できるのに対し、データベースは通常、Webアーキテクチャの一部で最も高価であり、拡張が最も難しいことに注意してください。
反対の例がいくつかありますが（Microsoft Sharepointなど）、通常、データベースにファイルを保存することはお勧めできません。
デスクトップアプリを作成したり、ユーザーの数を大まかに把握したりしない限り、公開Webサイトのようにランダムで予想外の場合は、データベースにファイルを保存するのに高額の費用がかかる可能性があります。
SQL Server 2008に移行できる場合は、両方の長所を提供するFILESTREAMサポートを利用できます。ファイルはファイルシステムに保存されますが、データベース統合は、varcharフィールドにファイルパスを保存するよりもはるかに優れています。クエリは標準の.NETファイルストリームを返すことができるため、統合が非常に簡単になります。
ここでの質問は何ですか？
最新のDBMSSQL2008には、テーブルに固定されているだけではないBLOBを処理するさまざまな方法があります。もちろん、長所と短所があり、もう少し深く考える必要があるかもしれません。
これは、故（？）ジム・グレイによる興味深い論文です。
パフォーマンスは問題ですが、最近のデータベース設計では、小さなファイルの問題ははるかに少なくなっていると思います。
パフォーマンスはさておき、データがどれだけ緊密に結合されているかにも依存します。ファイルにデータベースのフィールドに密接に関連するデータが含まれている場合、ファイルは概念的にその近くに属し、blobに格納される可能性があります。複数のレコードに関連する可能性のある情報が含まれている場合、またはデータベースのコンテキスト外で使用される可能性がある場合は、外部に属します。たとえば、Webページ上の画像は、それにリンクしているページとは別のリクエストでフェッチされるため、外部に属する場合があります（特定の設計とセキュリティの考慮事項によって異なります）。
私たちの妥協案は、それが最善であるとは約束していませんが、小さいXMLファイルをデータベースに保存し、画像やその他のファイルをデータベースの外部に保存することでした。
BLOB（イメージ）をバイト配列に解析し、それを適切なファイル名でディスクに書き込んでから読み取る必要があるオーバーヘッドは、特にファイルが次の場合に、これを頻繁に行うことを思いとどまらせるのに十分なオーバーヘッドヒットですかなり大きい。