Пространство, используемое нулями в базе данных

Question

Если столбец пуст, влияет ли это на пространство, используемое столбцом? Зафиксировано ли используемое пространство определением столбца? Отличается ли это от базы данных к базе данных. (В основном меня интересует SQL Server 2000.)

Пояснение: Вопрос не в том, что происходит, когда столбец «обнуляется» (как указал Критсен и Гбн, это стоит еще немного). Вопрос в том, есть ли сохранение, когда столбец фактически равен нулю (в какой-то конкретной строке).

...

Cadaeic предоставил ответ для SQL Server, который, по-видимому, не экономил в SQL Server до версии 2008, тогда как согласно Quassnoi вы можете получить экономию в Oracle, если нулевые столбцы находятся в конце. Спасибо за ответы, все они были полезны.

Answer 1

Хранение значения NULL в столбце не требует особых затрат или экономии места. Для данных фиксированной длины все пространство по-прежнему зарезервировано.

С другой стороны, для данных переменной длины требуется только длина данных плюс накладные расходы для хранения фактической длины. Например, VARCHAR (n) будет использовать 2 байта данных, чтобы указать эту фактическую длину, поэтому требуемое пространство для хранения всегда равно n + 2.

Кроме того, следует отметить, что если SET ANSI_PADDING ON, char (n) со значением NULL будет вести себя как VARCHAR (n).

Независимо от того, что вы не будете распознавать «экономию» пространства от хранения значений NULL при использовании SQL Server 2000 или SQL Server 2005. SQL Server 2008 представляет концепцию разреженного столбца, которая может обеспечить экономию для столбцов, которые в основном имеют значение NULL.

Answer 2

SQL Server имеет бит для обозначения NULL. Такой бит не используется, если столбец определен как NOT NULL

VARCHAR использует переменную длину для хранения данных (и, следовательно, имеет накладные расходы, указывающие, как долго действительные данные), тогда как CHAR - фиксированная ширина.

Таким образом, на этом основании CHAR (1) NOT NULL "короче", чем VARCHAR (1) NOT NULL, поскольку VARCHAR нужен индикатор длины, а CHAR всегда будет использовать только один байт.

РЕДАКТИРОВАТЬ: Обратите внимание, что наличие поля BIT, которое позволяет NULL, требует два бита для его хранения! Я часто вижу поля BIT, где это не учитывалось, не нужно хранить NULL, но для них не было установлено значение NOT NULL, поэтому они тратят немного непреднамеренно

Answer 3

В Oracle зависит от типа столбца и его положения в строке.

Если столбцы NULL являются последними в строке, тогда они вообще не занимают места. Oracle добавляет общий размер строки к каждой строке, все, что не подходит, считается NULL.

Если после столбца NULL есть некоторые не NULL данные, то NULL сохраняется как один байт 0xFF (то есть типа NULL).

Пусто VARCHAR2 эквивалентно NULL. Если вы протестируете тип литерала NULL, возвращенного из списка SELECT, он даст вам VARCHAR2(0).

Answer 4

Он хранится в растровом изображении, а не в виде значения столбца.

Пример: обнуляемый столбец varchar с именем отчество

• строка 1, «bob» сохраняется как смещение, 3 байта для bob, 2 байта для длины «bob»
• строка 2, строка NULL не сохраняется как значение типа «bob», но в заголовке строки

Если у вас не очень маленькая таблица, скажем, один столбец char (1), то она более эффективна

Ссылка 1 Ссылка 2

Answer 5

В Oracle 11G у меня тоже была такая же ситуация. Вы не можете освободить (проверить dba_segments) пространство, занимаемое существующими строками, установив столбец NULL независимо от его положения, в середине или в конце.

UPDATE AUCORE_QA.SYSTEM_AUDIT_LOGS SET KEY=NULL;
SELECT OWNER, TABLESPACE_NAME , SEGMENT_NAME,SEGMENT_TYPE,BYTES/1024/1024 MB
FROM DBA_SEGMENTS 
WHERE OWNER LIKE 'AUCORE_QA' AND SEGMENT_TYPE='TABLE' AND SEGMENT_NAME like '%AUDIT_LOG%'
ORDER BY BYTES DESC;

Тем не менее, я сделал столбец Nullable и смог увидеть экономию экономии для последующих вставленных строк.

ALTER TABLE SYSTEM_AUDIT_LOGS MODIFY KEY NULL;

Answer 6

Количество байтов, используемых строкой, меньше, если вы используете типы данных varchar или nvarchar. Вот почему вы можете создать таблицу (но не должна), которая имеет больше потенциальных байтов, чем может быть сохранено в записи.