2

我习惯于为 PostgreSQL 设计，它的字符类型没有性能差异，社区的建议是明确的限制只存在于执行业务规则。

https://www.postgresql.org/docs/current/datatype-character.html

现在我在 Oracle (19c) 工作。我对字符类型的选择似乎是具有强制限制的 VARCHAR2 或 CLOB。

社区的建议似乎是尽可能避免使用 CLOB。我不清楚这是出于性能原因、传统原因，还是因为 CLOB 在没有一些操作的情况下不会显示在查询编辑器中。

如果没有来自业务或领域的规则建议文本字段的最大长度，那么在选择限制时我应该考虑哪些技术、性能或用户体验因素？

4

2 回答 2

3

“这是否是出于性能原因” - 那个。CLOB 在 Oracle 中非常慢（尤其是如果您对它们进行了很多更改）

如果没有业务规则并且 4000 字节（！）暂时似乎就足够了，请使用varchar2(4000).

不要试图使用允许的扩展 varchars varchar2(32767)- 它们在后台存储为 CLOB 并遭受相同的性能问题。

于 2020-05-07T10:25:58.437 回答
1

TL;DR：避免使用 CLOB，使用合理长度的 VARCHAR2。

我完全同意@a_horse_with_no_name 关于 CLOB 和varchar2(32767).

但是，我不建议使用 的最大尺寸VARCHAR2(4000)，而是使用合理的上限，这实际上很难估计。如果字段太短，用户和其他开发人员会讨厌你。如果字段太长，数据库会做一些奇怪的事情。

因为VARCHAR2只存储实际使用的字符，所以在存储方面你不会发现任何差异，它在插入、更新或删除过程中的性能很可能是相同的。

但是，有时 Oracle 会假设实际使用了最大长度：

CREATE TABLE t (
  a VARCHAR2(   1 CHAR),
  b VARCHAR2(   1 CHAR),
  c VARCHAR2(4000 CHAR),
  d VARCHAR2(4000 CHAR)
);

CREATE INDEX i1 ON t(a,b);
Index I1 created.

CREATE INDEX i1000 ON t(c, d);
ORA-01450: maximum key length (6398) exceeded

此外，当数据库服务器（或客户端应用程序）按最大长度分配内存时，有时会影响性能，例如：

INSERT INTO t SELECT 'a','a','a','a' FROM all_objects;
INSERT INTO t SELECT 'b','b','b','b' FROM all_objects;
INSERT INTO t SELECT 'c','c','c','c' FROM all_objects;
INSERT INTO t SELECT 'd','d','d','d' FROM all_objects;
EXECUTE dbms_stats.gather_table_stats(null, 't');
SET AUTOTRACE TRACEONLY STAT

现在按列排序VARCHAR2(1)发生在内存中（速度很快）：

SELECT a,b FROM t ORDER BY a,b;

Statistics
----------------------------------------------------------
      1  sorts (memory)
      0  sorts (disk)
 268520  rows processed

虽然按VARCHAR2(4000)列排序不适合内存，因此必须在磁盘上排序，这很慢：

SELECT c,d FROM t ORDER BY c,d;

Statistics
----------------------------------------------------------
      0  sorts (memory)
      1  sorts (disk)
 268520  rows processed

我不得不承认，我将可用内存设置为非常小的数量只是为了证明这一点，但我想你明白了。

于 2020-05-16T09:22:11.367 回答