1

OracleではLongRawとVarchar2の最大長は4kbですが、8kbと16kbのオブジェクトを格納する必要があるため、どのような解決策があるのでしょうか。Blobを使用できることはわかっていますが、Blobの長さは可変であり、基本的に、オブジェクトの支払いに関心がない機能と価格が正しければ、舞台裏で追加のファイルになります。この種のニーズにより適した他のソリューションまたはデータ型はありますか？

ありがとう

4

5 に答える 5

3

BLOB は舞台裏のファイルではありません。データベースに格納されます。可変長であることはなぜ重要なのでしょうか? BLOB 列 (データがテキスト データの場合は CLOB) を使用するだけで、独自のセグメントに格納されます。

于 2009-02-12T08:50:20.967 に答える
2

バイナリデータをエンコードする意思がない限り（base64など）、varchar2列に格納しないでください。文字セットの問題により、データが破損する可能性があります。

次のステートメントを試して、効果を確認してください。

select * from（select rownum-1 original、ascii（chr（rownum-1））data from user_tab_columns where rownum <= 256）where original <> data;

于 2009-02-12T09:22:01.950 に答える
2

バイナリデータをセグメント化して4Kチャンクに保存してみませんか？これらのチャンク用に4つの異なる列（およびそれらを大きな構造に再構築するための長さ列）、またはチャンクを元のテーブルレコードに関連付けた別のテーブルのより正規化された方法のいずれかを使用できます。

これにより、将来必要になった場合に拡張が可能になります。

例えば：

Primary table:
    -- normal columns --
    chunk_id integer
    chunk_last_len integer
Chunk table:
    chunk_id integer
    chunk_sequence integer
    chunk varchar2(whatever)
    primary key (chunk_id,chunk_sequence)

もちろん、DBMSがBLOBの内部でまさにそのような動作をすることに気付くかもしれません。また、Oracleに処理させる方が効率的であり、個々のチャンクからデータを手動で再構築する必要がなくなります。それぞれのパフォーマンスを測定して、最善のアプローチを見つけます。

于 2009-02-12T07:48:16.730 に答える
2

BLOB を使用する必要があります。

BLOB は追加のファイルとして保存されるのではなく、(他のデータと同様に) データファイルの 1 つにブロックとして保存されます。BLOB が 1 つのブロックに対して大きくなりすぎた場合 (このケースでは発生しない可能性があります)、別のブロックで続行されます。

BLOB データが非常に小さい場合は、Oracle に行内の他のデータ (varchar2 など) と一緒にインラインで格納させることができます。

内部的には、Oracle は PAX が提案したものと同様のことを行っています。チャンクは、DB ブロックからオーバーヘッドを差し引いた大きさです。Oracle の上に Oracle 機能を再発明しようとすると、ネイティブ機能よりも遅くなるだけです。

また、DBMS_LOB ですでに提供されている機能 (長さ、比較など) のヒープ全体を再実装する必要があります。

于 2009-02-12T11:17:40.190 に答える
1

Varchar2も同様に可変長です。小さいサイズよりも大きいバイナリデータをデータベースに保存する必要がある場合は、blobの方向を調べる必要があります。別の解決策は、もちろん、バイナリをファイルシステムのどこかに保存し、ファイルへのパスをvarcharとしてデータベースに保存することです。

于 2009-02-12T07:47:24.503 に答える