在 Oracle 中使用小 blob 是否合理？答案

【问题标题】：Is it reasonable to use small blobs in Oracle?在 Oracle 中使用小 blob 是否合理？
【发布时间】：2010-10-07 02:58:20
【问题描述】：

在 Oracle 中，LongRaw 和 Varchar2 在 Oracle 中的最大长度为 4kb，但我需要存储 8kb 和 16kb 的对象，所以我想知道什么是好的解决方案。我知道我可以使用 Blob，但 Blob 具有可变长度，如果我是正确的，它基本上是幕后的一个额外文件，一个我不想为我的对象支付的功能和价格。还有其他更适合这种需求的解决方案或数据类型吗？

谢谢

【问题讨论】：

标签： oracle blob

【解决方案1】：

blob 不是幕后的文件。它存储在数据库中。为什么它具有可变长度很重要？您可以只使用 blob 列（如果您的数据是文本数据，则可以使用 clob）并将其存储在自己的段中。

【讨论】：

【解决方案2】：

您应该使用 BLOB。

BLOB 不作为额外文件存储，它作为一个块存储在您的一个数据文件中（就像其他数据一样）。如果 BLOB 对于单个块来说太大（在您的情况下可能不会发生），那么它将在另一个块中继续。

如果您的 BLOB 数据非常小，您可以让 Oracle 将其与行中的其他数据内联存储（如 varchar2）。

在内部，Oracle 正在做一些类似于 PAX 建议的事情。这些块与减去一些开销的 DB 块一样大。如果您尝试在 Oracle 之上重新发明 Oracle 功能，它只会比本机功能慢。

您还必须重新实现已经在 DBMS_LOB 中提供的一大堆功能（长度、比较等）。

【讨论】：

【解决方案3】：

为什么不分割二进制数据并将其存储在 4K 块中？您可以为这些块设置四个不同的列（以及一个用于将它们重建到大结构中的长度列），或者使用另一个表的更规范化的方式，其中的块与原始表记录相关联。

这将在您将来需要时提供扩展。

例如：

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 处理它可能会更有效，从而使您无需手动从各个块中重建数据。我会衡量每个人的表现以找出最佳方法。

【讨论】：

这是我正在考虑的解决方案，但有点希望有一个“更好”的标准解决方案，无论如何我想我会这样做，除非有人有更好的主意
更好的解决方案是首先使用 BLOB。

【解决方案4】：

不要将二进制数据存储在 varchar2 列中，除非您愿意对它们进行编码（base64 或类似的）。否则字符集问题可能会损坏您的数据！

试试下面的语句看看效果：

select * from (select rownum-1 original, ascii(chr(rownum-1)) data from user_tab_columns where rownumdata;

【讨论】：

忘记了这个！

【解决方案5】：

Varchar2 也是可变长度的。如果您需要在数据库中存储任何大于小尺寸的二进制数据，则必须查看 blob 的方向。另一个解决方案当然是将二进制文件存储在文件系统的某个位置，并将文件的路径作为 varchar 存储在 db 中。

【讨论】：

是的，文件解决方案是一种可能，但我希望将其全部保存在数据库中，因为我需要复制/集群功能。有了这个文件，我想我需要推出自己的集群。