Текст в свободной форме

А как насчет доменов Comments (Комментарии) и Description (Описание)? Их наличие говорит о том, что определение таблицы будет включать описательный столбец. Какой же размер для него установить? При принятии такого решения необходимо учитьгвать следующие факторы:

какова процентная доля записей, которые будут снабжены комментарием или описанием;

будет ли достаточно 2000 символов (максимальное количество символов для типа VARCHAR2);

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

какие инструменты пользователь будет иметь в своем распоряжении для редактирования этого текста;

какие виды запросов будут производиться к этому тексту.

В Oracle версии 5 для большинства проектов просто выбиралось 240-сим-вольное поле. В версии 6, где максимальный размер символьной строки был увеличен, эта величина возросла до 255. Для Oracle? самое простое решение - использовать VARCHAR2(2000). В этом случае можно будет хранить довольно объемные комментарии.* В программе обработки экранной формы можно реализовать механизм, позволяющий пользователю работать с текстом в этом поле как с обычным документом, т.е. добавлять, соединять строки, перемещать их и т.п.

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

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

Если существует вероятность того, что объем комментариев и замечаний со временем увеличиться, можно использовать следующий подход - создать справочную таблицу, в каждой строке которой содержится одна строка комментария или описания. Эта таблица помещается в однотабличный кластер с кластерным ключом, совпадающим с первичным ключом главной таблицы, как показано в следующем примере:

CREATE CLUSTER case notes c ( caset VARCHAR2(12) ); CREATE INDEX ON CLUSTER case notes;

В некоторых версиях Oracle известна проблема, связанная с VARCHAR2(2000): полное наполнение его в одном экземпляре может привести к возникновению ошибки ORA-I467: Sort key loo long при сортировке этой таблицы по любому неиндексированному столбцу.

CREATE TABLE case notes

( case# VARCHAR2(12)

, line* NUMBER(3) NOT NULL

, made at DATE NOT NULL

, text VARCHAR2(80)

) CLUSTER case notes c ( case* );

Этот метод обладает рядом полезных особенностей:

в таблице CUSTS не потребляется пространство для комментариев о клиентах, не имеющих значения для пакетной обработки, в результате чего сокращается объем операций ввода-вывода;

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

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

При этом, Однако, возникает и ряд проблем;

для загрузки кластеров требуется время, поэтому всякая реорганизация или операция EXPort/IMPort будет длиться значительно дольще (фактически в несколько раз дольще);

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

Неструктурированные данные и BLOB

Некоторые данные не умещаются в таблицах, содержащих относительно узкие и хорошо отформатированные столбцы. Например, может понадобиться база данных для хранения текста, звука, графики, мультимедиа и других типов данных, известных как BLOB (Binary Large Object - большие двоичные объекты). Хранение этих элементов в базе данных выгодно с точки зрения инкапсуляции, но невыгодно вследствие ограничений, которые Oracle налагает на столбцы типа LONG или LONG RAW (а именно в столбцах этого типа мы обычно храним такие данные). Вот эти ограничения:

Их использование не позволяет перемещать и копировать строки с помощью SQL-предложения

INSERT INTO а SELECT * FROM b;

которое является самым быстрым способом перемещения данных в базе данных Oracle.

Отсутствует возможность ссылки на столбцы LONG в условии предложения.

Когда делается ссылка на часть строки, то всю строку приходится собирать в буферном пуле Oracle. Если значение типа LONG требуется не всегда, то лучше разместить его в отдельной таблице - либо с использованием связи один к одному , либо путем разделения его на произвольное число элементов и хранения их в справочной таблице.

Если по какой-либо из вышеизложенных причин мы хотим избежать использования столбца LONG, то следует рассмотреть возможность хранения BLOB вне базы данных (вероятно, в файле на хост-компьютере). Тогда строка будет просто содержать полное имя внешнего файла. Приемлемость этого варианта зависит от конкретного приложения. Если вы все же решили его использовать, имейте в виду следующее:

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

- Нет механизма, который обеспечивал бы обновление имени файла в базе данных при его перемещении или переименовании. Аналогичным образом, если файл удаляется внешней командой, то в таблице не будет сведений о потере данных.

- Внесенные в файл изменения не являются объектом операции фиксации базы данных, поэтому синхронность содержимого файла и строки в таблице не гарантируется.

- Вам придется ввести правила именования файлов, содержащих BLOB, или средство размещения их в разных каталогах. Это особенно важно, если ожидается, что в таблице будет много строк и, следовательно, много файлов.

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

Нас заставляют надеяться, что в следующих версиях Oracle все эти проблемы будут решены, но на данный момент мы должны проявлять осмотрительность, когда речь идет об использовании РСУБД в качестве хранилища больших двоичных объектов.

Другие типы данных

в данном разделе мы рассмотрим еще пять типов данных из имеющихся в Oracle и более подробно опишем тип CHAR. Два типа - MLSLABEL и RAW MLSLABEL - используются только в Trusted Oracle, и их рассмотрение выходит за рамки нашей книги.

1А 1