44

これは以前 ( large-text-and-images-in-sql )に尋ねられた質問ですが、主に変更されるデータについてです。私の場合、データは保存され、変更されることはありません。すべてをまとめておくのが賢明なようです。

静的バイナリ データをデータベースに格納してはいけない理由はありますか?

それが賢明なことであると仮定すると、そのようなデータを別のテーブルに格納する利点はありますか? (私が DB の専門家ではないことに気付き始めるかもしれません...)

明確化: ユーザー数はおそらく 10 ~ 20 人程度ですが、これらは米国と英国に存在します。いずれの場合も、バイナリ データを転送する必要があります。

4

11 に答える 11

34

DB にデータを格納する利点は、DB のセキュリティ メカニズムを活用し、メンテナンス コスト (バックアップなど) を削減できることです。これの欠点は、DB の負荷が増加し、接続を消費することです (接続ごとにライセンスされたデータベース サーバーでは費用がかかる可能性があります)。SQL Server 2008 を使用している場合はFILESTREAM、良い代替手段になる可能性があります。

ところで、Web アプリ (またはデータのストリーミングが必要なその他のアプリ) の場合、通常は DB の外部にデータを格納する方が賢明です。

于 2009-03-19T14:50:34.363 に答える
12

テーブルに LOB がある場合に巨大なメモリや帯域幅の問題を引き起こす "select * from table" の実行についてのこのすべての話は、問題ではありません。返されるのは、問題の LOB へのポインタだけです。コメントを文脈に入れるには十分な評判ではありませんが、これを見ている人はそれが問題ではないことを知っているはずです.

于 2011-06-08T17:44:59.570 に答える
9

BLOBS を保存する場合の最大の欠点は、メモリの消費です。select * from x がそれぞれ 45k の画像を含む何千ものレコードに対して何をするか想像できますか?

Mehrdad が言ったように、利点もあります。そのため、そのアプローチを採用する場合は、データベースを設計して、ほとんどのクエリが BLOB データを含む結果をあまり返さないようにする必要があります。たとえば、この目的のために 1 対 1 の関係を作成します。

于 2009-03-19T14:57:46.343 に答える
7

私は、MySQL データベースにイメージを保存することを開始時に決定した、かなり大きな規模の OSS プロジェクトに精通しており、それ以来、彼らが対処してきた悪いアイデアのトップ 3 に入ることが証明されています。(「無慈悲なリファクタリング」が忌み嫌われているという事実によって悪化しますが、それは別の話です。)

これによって引き起こされた深刻な問題には、次のようなものがあります。

  1. 効率的なデータベースの最大サイズ (mysql) を超えています。(画像に必要な合計スペースは、他のすべてのスペースを少なくとも 2 桁上回っています)。

  2. 画像ファイルは「ファイル性」を失います。日付として(冗長に)保存されない限り、日付のサイズなどはありません(管理用のコードが必要です)。

  3. 任意のバイト シーケンスは、保存または操作のいずれにおいても、常に適切に処理されるわけではありません。

  4. 「外部から画像にアクセスする必要はない」というのは危険な仮定です。

  5. もろさ。全体の配置が不自然で微妙で、次にどこに引っかかるかわからないからです (反リファクタリングの考え方に貢献します)。

メリット?それが当時最も抵抗の少ない道だったかもしれないことを除いて、私が考えることができるものはありません.

于 2009-03-19T16:26:47.773 に答える
7

原則の観点から問題に対処すると、リレーショナル データベースは (主に) 構造化データを格納するために存在します。データ要素に対してクエリ条件を作成したり結合したりできない場合は、おそらくデータベースに属していません。イメージ BLOB が WHERE 句で使用されているとは思わないので、データベースの外に置いておくといいでしょう。一方、CLOB はクエリで使用できます。

于 2010-06-10T12:54:32.530 に答える
5

これは建物の用途によると思います。CMS システムを構築していて、データを使用して Web ブラウザー内に画像を表示する場合、画像をデータベースに保存するのではなく、ディスクに保存する方が理にかなっています。正直なところ、私は両方を実行しますが、ファイルをあちこちにコピーすることなく、ファームにサーバーを追加できます。

もう 1 つのユース ケースは、ワークフローなどの複雑なオブジェクトであったり、多くの相互依存関係を持つビジネス オブジェクトであったりします。これらの両方をバイナリまたはテキストベースの形式にシリアル化し、DB に保存できます。次に、ATOMIC、バックアップなどの DB のメリットを享受できます。

select *そもそもクエリを使うべきではないと思います。行うことは、データを取得する 2 つの方法を提供することです。1 つのメソッドは概要情報を返し、2 つ目は BLOB を返します。なぜ一度に何千もの画像を返す必要があるのか​​ 想像できません。

于 2009-03-19T15:09:25.410 に答える
2

添付ファイルはシステムに保存されますが、添付ファイルを変更することはできません。そのため、「保存され、変更されることはない」データと同じページにいると思います。データベースに保存しないことにしました。これを行った理由は、シンプルさとバックアップ/リカバリ時間の 2 つです。

シンプルさ第一: 私たちの場合、これらの添付ファイルはエンドユーザーのブラウザからアップロードされ、SQL パイプを介してストリーミングするよりも、(DB サーバー上の) ディレクトリに書き込む方が簡単です。それらのレコードは DB にありますが、DB には添付ファイルに関するメタ情報と、ディスク上のファイルの名前 (この場合は GUID) が含まれているだけです。

バックアップ/リカバリ側: これらの BLOB は、データベースの最大の部分の 1 つになる可能性があります。完全バックアップを実行すると、決して変更できないことがわかっていても、これらのビットを何度もコピーすることになります。私たちには、(はるかに) 小さいバックアップを作成し、バックアップとしてセカンダリ サーバーに添付ファイル ディレクトリの xcopy を実行する方がはるかに簡単に思えました。

于 2009-03-19T15:55:40.860 に答える
2

これはまさに LOB、CLOB、または .... が設計された目的ではありませんか?

私たちは CLOB を使用して、主要な航空システムのクレジット カード カード トランザクションの大規模な暗号化を格納しました。

ただし、メモリ消費が最大の原因です。

HTH

乾杯、

于 2009-03-19T15:01:00.327 に答える
1

ここでのパフォーマンスの問題は上記のとおりであるため、繰り返しません。しかし、大量にストリーミングされるもの (Web サイト上の画像やドキュメントなど) を保存する場合の良いヒントは、キャッシュ システムを構築することだと思います。

これは、すべてのデータをデータベースに保存することを意味しますが、誰かがそのファイルを要求したときに、ディスク上に存在するかどうかを確認し (一時フォルダー内の既知のファイル名に基づいて)、存在しない場合は、DB から取得して書き込みますフォルダを作成し、それをユーザーにストリーミングします。同じファイルへの次のリクエストでは、ディスク上に存在するため、DB にヒットすることなくそこからサービスを提供できます。しかし、これらのファイルを削除する必要がある場合 (または Web サーバーが壊れてしまう場合) は、人々が要求したときに DB から再構築されるため問題ありません。これは、DB から同じファイルの各リクエストを処理するよりもはるかに高速です。

于 2009-03-19T16:07:48.723 に答える
1

一部のデータベース (Postgresql など) は、フィールドを自動的に圧縮します。おそらく、db から直接読み取る方が高速です。また、プログラムはすべてのフィールドと画像を一度に読み取ることができます。

于 2009-03-19T15:14:03.790 に答える