CHAR

Как мы уже говорили, данные типа CHAR имеют фиксированную длину. Любой столбец типа CHAR(255), значения которого определены (NOT NULL), занимает 255 байтов дискового пространства в каждой строке содержащей его таблицы (это плохая новость), а также 255 байтов в листьевом наборе любого индекса, в который он включен (это еще худщая новость).

Использование типа CHAR, а не VARCHAR2, очень редко дает преимущество, за исключением слуия, когда строка имеет фиксированную длину и вы хотите фиксировать ее как таковую. Oracle в настоящий момент не поддерживает строки нулевой длины, и пустая строка рассматривается (ошибочно) как неопределенное (NULL) значение. По Этой причине VARCHAR2(1) не является бессмыслицей из-за того, что длина здесь может быть равна только единице. Она не может быть равна нулю из-за реализационного ограничения и не может быть больше единицы по определению. Поэтому мы рекомендуем хранить односимвольные строки (например, флаги истина/ложь ) как CHAR(l).

Основное различие между типами RAW и VARCHAR2 состоит в том, что данные типа RAW никогда не переводятся из одного набора символа в другой. Кроме того, инструментальные средства Oracle в целом отказываются обрабатывать данные типа RAW. Поэтому, используя этот тип, вы, по сути, принимаете на себя всю ответственность за операции с ними.

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

ROWID

Этот тип данных позволяет хранить идентификатор строки (rowid) в его внутреннем шестибайтном виде, который включает номер блока ядра, номер строки и номер файла. Хотя тип ROWID и применяется Oracle в некоторых операциях со словарем данньи (например, для хранения ссылок на строки, нарушающие ограничения), он необходим только для синтеза внешнего ключа к таблице, не имеющей возможного первичного ключа.

Поскольку в Oracle (в отличие от DB/2) не требуется, чтобы таблица имела первичный ключ, то коллектив разработчиков ядра Oracle вынужден был в описанном выше случае использовать внутренний указатель (rowid), в котором таблица базы данных хранит строку для каждой строки другой таблицы, которая нарушает ограничение.

Мы не рекомендуем применять тип данных ROWID внутри таблицы. Сушествуют редкие случаи, когда его использование оправдано при определении представления - чтобы представление могло передать идентификатор строки в запрос для последующего использования его в

предложении UPDATE или DELETE. Однако следует помнить, что такую операцию перед выдачей запроса необходимо защитить эксклюзивной блокировкой на уровне таблицы.

VARCHAR

Определение этого типа данных в настоящее время совпадает с определением VARCHAR2, однако между этими типами есть важное различие. Корпорация Oracle заявила, что если будущий (а не предлагаемый) стандарт SQL будет содержать определение назначения VARCHAR, то корпорация будет придерживаться этого стандарта. Тем не менее, определение VARCHAR2 они не изменят (если только он тоже не будет назван в стандарте, что весьма маловероятно).

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

Выще, рассматривая тип CHAR, мы говорили, что Oracle поступает неверно, трактуя строки нулевой длины как неопределенные значения. Конечно, на эту тему можно поспорить, но мы рассматриваем строку нулевой длины как аналог числа нуль. Oracle выразила намерение реализовать в OracleS хранение строк нулевой длины и обеспечить их отличие от неопределенных значений. Мы еще не знаем, потребует ли это использования нового типа данных или же эта поддержка ознаменует собой изменение в VARCHAR. Возможно, это нельзя будет применить к VARCHAR2, так как это означало бы серьезное изменение принципов функционирования и испортило бы намерение держать VARCHAR2 на первых ролях.

Неопределенные значения

Неопределенные (NULL) значения являются одним из предметов, вокруг которого уже много лет бущуют дебаты. В частности, больше года в журнале Database Programming and Design ведутся жаркие дискуссии на эту тему с участием таких ключевых в области баз данных фигур, как Крис Дейт. Даже У авторов этой книги есть различия во мнениях по этому вопросу. Мы не будем углубляться здесь в философские размышления, а просто изучим некоторые особенности неопределенных значений и приведем примеры связанных с ними проектных решений.

Смысл неопределенного значения

Неопределенное значение отличается от всех остальные значений следующим:

Если оно используется в функции или выражении, то результатом всегда будет неопределенное значение - даже несмотря на то, что после

конкатенации неопределенного значения со строкой последняя остается без изменений.

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

Полностью неопределенные ключи никогда не хранятся в индексе Oracle; частично неопределенные ключи хранятся, но на их использование существует ряд ограничений (которые описаны ниже).

Неопределенное значение может интерпретироваться по-разному.

В больщинстве ЗСЬ-языков и базовых языков неопределенное значение представить невозможно.

Давайте рассмотрим вопрос интерпретации неопределенного значения. Оно может соответствовать как минимум одному из элементов следующего списка и, вероятно, еще массе других вещей, здесь не указанных;

не применимо;

не известно;

не задано;

на данный момент не известно (будет указано позже);

было задано, но сейчас устарело (обновлено в неопределенное значение);

отсутствует (возможно, по соображениям безопасности).

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

Одни самозваные эксперты говорят, что реляционная база данных должна поддерживать более одного типа неопределенных значений. Другие вообще выступают против их применения из-за непредсказуемости поведения, вызванной использованием многозначной логики (МЗЛ) вместо двузначной (23Л). Все эти аргументы основаны на том, что булев оператор, обычно возвращающий ответ True (истина) или False (ложь), может возвратить третье значение, если любой из аргументов имеет неопределенное значение. Это третье значение (Unspecified - не задано) в сочетании с NOT может привести к очень туманному четвертому значению.