Самое главное при выборе типов данных - обеспечение непротиворечивости. Если вы определите номер шасси автомобиля в одной таблице как ]4lUMBER(ll), а в другой как VARCHAR(15), то, когда дело дойдет до соединения этих таблиц, неприятности вам обеспечены. Напишите SQL-предложение для сравнения 918273645 и 918-27-36/4/5 . Говорите, запросто? Тогда напишите его так, чтобы оно эффективно работало в предложении, выполняющем соединение!

Числовые данные

Существует два типа числовых данных:

1. Целые и вещественные значения (например, сальдо банковского счета или ставка процента). Они являются объектом математической обработки.

2. Строковые данные, в которых единственно допустимыми символами являются цифры (например, номера банковских счетов).

Целые и вещественные значения

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

Многие проектировщики попросту игнорируют эти требования и не указывают ни систему счисления, ни точность:

, length NUMBER CHECK (length BETWEEN 0 AND 100) , height NUMBER CHECK (height BETWEEN 0 AND 50) , width NUMBER CHECK (width BETWEEN 0 AND 100)

Такое определение работает, но может потребовать неожиданно большого объема памяти. Oracle хранит числа в двоично-десятичном формате с плавающей точкой, а не в двоичном формате с плавающей точкой. Кроме того, они хранятся как числа переменной длины. Любое целое число (например, 123226334) можно точно преобразовать из двоичного в десятичное и наоборот, однако с вещественными числами это можно сделать очень редко. Поэтому если в С-программе есть представление числа 10,2 в двоичном формате с плавающей точкой, то оно будет вставлено в Oracle как 38-значное значение, которое будет очень-очень близко к 10,2, но не абсолютно равно этому числу. Этот эффект трудно продемонстрировать без ЗСЕ-программы, потому что все инструменты Oracle широко используют десятичный формат Oracle с плавающей точкой. Эту проблему демонстрирует следующий диалог на SQL*Plus:

SQL> set numwidth 40

SQL> select 1/8 fraction from dual;

FRACTION

.125

SQL> select 1/7 fraction from dual; FRACTION

.142 85714 42 857142857142 85714285714 3

К счастью, существует давно предложенное но редко используемое рещение. Оно позволяет ограничивать точность числа в Oracle так, чтобы в формате с плавающей точкой оно было представлено определенным числом битов (обычно 32 или 64). Вот этот синтаксис:

, length FLOAT(64) CHECK (length BETWEEN 0 AND 100) , height FLOAT(32) CHECK (height BETWEEN 0 AND 50) , width FLOAT(64) CHECK (width BETWEEN 0 AND 100)

Мы рекомендуем всегда ограничивать разрядность целых чисел, используя NUMBER(nn), а для чисел с плавающей точкой задавать требуемую точность при помощи FLOAT(nn). У вас может возникнуть вопрос, а стоит ли экономить несколько байтов, когда диск так дещев. Мы отвечаем на него так:

Это очень легко реализовать.

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

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

IIpiLMCHOHiie

Не рекомендуем использовать типы данных INTEGER, SMALLINT и REAL. Несмотря на то, что Oracle поддерживает эти ключевые слова в DDL-предложениях, в словаре данных они не поддерживаются. Эти типы интерпретируются как NUMBER(38), NUMBER(38) и FLOAT(63) соответственно, и вы, вероятно, понимаете, что 38-значное число никак нельзя назвать как SMALLINT!

Строки цифр

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

10 /I

последовательности? Что лучше использовать - столбцы типа NUMBER или VARCHAR2? Здесь следует учесть несколько факторов.

Если число содержит ведущие нули, то при сохранении его в столбце типа NUMBER, они не записываются. Следовательно, если домен номеров счетов включает, например, число 0321234, то база данных примет его, но не сможет отличить от 321234, даже несмотря на то, что найдет при получении запроса на число 0321234. Таким образом, если 321234 и 0321234 допустимые, но разные номера счетов, возникают серьезные проблемы.

Если вы используете фразу ORDER BY с типом VARCHAR, то Oracle отсортирует значения с применением символьной сортировки и значения будут возвращены в следующем порядке: 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 2, 20... . Указав столбец типа VARCHAR как аргумент функции TO NUMBER, мы решим эту проблему, но не сможем использовать для сортировки индекс. Конечно, если в операторе INSERT мы набьем эти значения слева нулями, то последовательность сортировки будет правильной и индекс можно будет использовать. Однако этот подход сопряжен с интенсивным потреблением дискового пространства, поэтому приходится решать, приемлем ли он для данных. Будут ли данные выглядеть правильно при таком подходе и не измениться ли их смысл?

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

ss no NUMBER(9) CONSTRAINT cc valid ss CHECK (ss no < 711111111)

более эффективна и менее подвержена ошибкам, нежели

ss no VARCHAR2(9) CONSTRAINT cc valid ss CHECK (ss no < 711111111)

где используется последовательность сортировки по кодам ASCII (и значение 9 не годится). Если вы все же хотите указать VARCHAR в данном случае, то лучше воспользоваться такой формой:

ss no VARCHAR2(9) CONSTRAINT cc valid ss CHECK (to number (ss no) < 711111111)

Мы предпочитаем использовать для строк цифр тип NUMBER. Главным исключением является случай, когда важное значение имеют ведущие нули.

Дата и время

Хранить даты очень просто, не правда ли? Мы используем столбец типа Date, потому что других возможностей в Oracle не предусмотрено. Однако это не совсем так. В действительности здесь есть несколько вариантов, и от выбора варианта может существенно зависеть надежность и производительность приложения.