Какой предел я должен установить для типов символов Oracle, если бизнес-ограничений нет?

Question

Я привык проектировать для PostgreSQL, чьи типы символов не имеют различий в производительности и где совет сообщества состоит в том, что явное ограничение существует только для обеспечения соблюдения бизнес-правила.

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

Сейчас работаю в Oracle (19 c). Мой выбор для типов символов, кажется, либо VARCHAR2 с обязательным пределом, либо CLOB.

Похоже, что сообщество советует избегать CLOB везде, где это возможно. Мне не ясно, связано ли это с производительностью, традициями или потому, что CLOB не отображаются в редакторах запросов без каких-либо манипуляций.

максимальная длина текстового поля, какие технические факторы, факторы производительности или взаимодействия с пользователем следует учитывать при выборе ограничения?

Answer 1

" ли это из соображений производительности " - то. CLOB очень медленные в Oracle (особенно если вы их много меняете)

Если нет бизнес-правила и 4000 байтов (!) Кажется достаточно на данный момент, go с varchar2(4000).

Не поддавайтесь соблазну использовать расширенные символы varchars, которые позволяют varchar2(32767) - они хранятся как CLOB в фоновом режиме и имеют те же проблемы с производительностью.

Answer 2

TL; DR: Избегайте CLOB, используйте VARCHAR2 с разумной длиной.

Я полностью согласен с @a_horse_with_no_name относительно CLOB и varchar2(32767).

Однако, Я бы не рекомендовал максимальный размер для VARCHAR2(4000), но использовать разумный верхний предел, который на самом деле довольно сложно оценить. Пользователи и другие разработчики будут ненавидеть вас, если поле будет слишком коротким. И база данных будет делать странные вещи, если поле слишком длинное.

Поскольку VARCHAR2 хранит только фактические используемые символы, вы не найдете никакой разницы на стороне хранилища, это производительность во время вставки, обновления или delete, скорее всего, идентичен.

Однако иногда 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

Кроме того, иногда возникает влияние на производительность, когда сервер базы данных (или клиент application) выделяет память по максимальной длине, например:

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

Я должен признать, что я установил доступную память на очень малое количество просто для того, чтобы докажите, но я думаю, вы уловили идею.