Почему Oracle varchar2 имеет обязательный размер в качестве параметра определения?

Ответ 1

Точно так же, чтобы определить тип varchar2 (10) или varchar2 (1000).

Нет, это совсем не то же самое.

• Длина столбца - полезные метаданные для разработчиков, создающих экраны.
• Аналогично, автоматические инструменты запросов, такие как TOAD и SQL Developer, используют длину столбца при рендеринге результатов.
• База данных использует длину переменной при распределении памяти для коллекций PL/SQL. Поскольку эта память выходит из PGA, переопределение объявления переменной может привести к сбою программ, поскольку на сервере закончилась нехватка памяти.
• Существуют аналогичные проблемы с объявлением отдельных переменных в программах PL/SQL, а именно, что коллекции, как правило, увеличивают проблему.
• Перечисленные столбцы создают проблемы для составных индексов. Ниже приведена база данных с блоками 8K.

....

SQL> create table t23 (col1 varchar2(4000), col2 varchar2(4000))
  2  /

Table created.

SQL> create index t23_i on t23(col1,col2)
  2  /
create index t23_i on t23(col1,col2)
                      *
ERROR at line 1:
ORA-01450: maximum key length (6398) exceeded


SQL>

Но, прежде всего, размеры столбцов - это форма проверки ошибок. Если в столбце должно быть десять символов, а какой-то автономный процесс пытается загрузить тысячу символов, то что-то не так. Процесс должен потерпеть неудачу, поэтому мы можем исследовать, почему мы загружаем данные Duff. Альтернативой является база данных, полная мусора, и если это то, что нужно, мы должны просто предоставить всем Excel и сделать с ней.

Правда, изменение размера столбца, если окажется, что мы недооценили, может быть утомительным. Но это происходит не очень часто, и мы можем смягчить большую боль, используя объявления% TYPE и SUBTYPE в нашем PL/SQL вместо жестких переменных длины переменной.

"почему нет такого объявления в типе NUMBER"

Номера разные. Для начала максимальный размер числа намного меньше, чем текстовый эквивалент (38 цифр гарантированной точности).

Но главное отличие заключается в том, что Oracle хранит числовые значения в научной нотации, поэтому между арифметическим размером номера и занимаемое им место хранения.

SQL> select vsize(123456789012345678901) n1
  2         , vsize(999999999999999999999999999999) n2
  3         , vsize(0.000000000000000000001) n3
  4         , vsize(1000000000000000000000000) n4
  5  from dual
  6  /

        N1         N2         N3         N4
---------- ---------- ---------- ----------
        12         16          2          2

SQL> 

Тем не менее, остается хорошей практикой определять масштаб и точность везде, где это возможно, особенно когда мы имеем дело с целыми числами, скажем, или деньгами.

Ответ 2

Я думаю, важно запомнить исторический контекст, в котором были разработаны реляционные базы данных. В то время, когда они разрабатывались (в конце 70 - начале 80-х), обычно доступные компьютеры были намного меньше (с точки зрения памяти и дискового пространства) и менее мощные (с точки зрения ЦП), чем у нас сейчас, и управление этими ресурсами было обязательно неотложная озабоченность. COBOL был общим языком бизнес-вычислений (и по-прежнему широко используется), а объектно-ориентированные языки, такие как Smalltalk и С++, были неизвестны для всех практических целей. В то время ожидалось, что программы будут точно указывать, сколько хранилищ им потребуется для каждого элемента данных, например. 10 байтов для строки, 2 байта для короткого целого числа, 4 байта для float и т.д., И поэтому этот стиль объявления использовался недавно разработанными реляционными базами данных. Более того, было сделано предположение , что каждый элемент данных объявлял (неявно или явно) объем требуемого хранилища, и это было закодировано в реляционных двигателях на очень фундаментальном уровне.

Теперь, со временем это требование несколько смягчилось, по крайней мере, до момента хранения данных на диске. Я считаю, что в Oracle тип данных NUMBER будет гибко распределять пространство, так что фактически используется минимальное пространство, необходимое для хранения его значения, и что столбцы VARCHAR2 будут использовать только достаточное дисковое пространство для хранения фактических данных без сохранения завершающих пробелов, хотя вам все равно нужно объявить максимальный объем памяти, необходимый для VARCHAR2.

Вы можете взглянуть на пакет SYS.STANDARD, чтобы получить представление о том, как объявить подтипы VARCHAR2. Например, если вам нужен собственный тип "string", который вы можете использовать без привязки к спецификации длины, вы можете попробовать:

SUBTYPE MY_STRING IS VARCHAR2(4000);

Однако будьте осторожны, если вы собираетесь индексировать соответствующий столбец (как указывалось ранее @APC).

Я согласен с тем, что я бы просто хотел объявить STRING (который, BTW, определенный в SYS.STANDARD как подтип VARCHAR2) без объявления длины, но это не так, как работает Oracle, и поскольку я не собираюсь начинать писать собственную реляционную базу данных (у меня есть свои ветряные мельницы, на которых можно наклонить, спасибо:-) Я просто соглашусь с статус-кво.

Надеюсь, это поможет.

Ответ 3

Почему бы не каждый столбец в каждой таблице базы данных быть CLOB? Таким образом, вам не нужно беспокоиться о максимальной длине...

Но, серьезно:

Ограничения длины типа данных существуют по той же причине, что и любые ограничения: они уменьшают количество проверок ошибок, необходимых для пополнения всего кода приложения, гарантируя, что любые данные, успешно сохраненные в таблице, соответствуют ограничениям, ve определено.

Ответ 4

Несмотря на то, что он не выделяет заданное количество байтов на диске, например поле char, есть еще достойные причины для выбора размера:

• Распределение памяти для считывателей данных (на основе максимального размера строки)
• Индексирование большого столбца приносит размеры блоков в игру
• Etc...

Я уверен, что есть другие причины, о которых может подумать другой человек, но это те, которые я видел в прошлом проекте, где кто-то выбрал varchar2(4000) все.

Ответ 5

С точки зрения извлечения информации, очень полезно знать, насколько велика область. Например, если вам нужно распечатать адрес на конверте или отобразить его на экране, вы хотите узнать, насколько велика область.

Или купить ОЧЕНЬ большие конверты.

Ответ 6

Возможное влияние на производительность: в MySQL, temporary tables и MEMORY tables хранят столбец VARCHAR в качестве столбца фиксированной длины, заполненный до максимальной длины.

Если вы создаете столбцы VARCHAR, намного превышающие требуемый размер, вы будете потреблять больше памяти, чем вам нужно. Это влияет на cache efficiency, sorting speed, etc.

Итак, вы даете максимальную длину, которая находится под вашей строкой. например, если у вас максимальная длина символа 10, поэтому не давайте его длину 100 или больше.