Данные какого типа будут храниться в столбце?

Первое, что прихохшт на ум в процессе выбора типа данных столбца, - это вопрос, какие данные будет содержать данный столбец Обычно происходит самое очевидное, числа хранятся в столбцах числового типа, строки хранятся в столбцах строкового типа, а даты и время хранятся в столбцах календарного типа и т.д. Когда число имеет дробную часть, логичнее будет выбрать не целочисленный тип, а тип с плавающей запятой. Но могут быть и исключения. Главным здесь может быть глубокое понимание природы данных. Это позволит выбирать тип данных, полностью вооруживщись знанием о предмете. Очевидно, что при работе с собственными данными, природа которых вам хорощо известна, это проблемы не составляет. Но когда таблица создается для других - это совсем другая история. Совсем непросто узнать, с чем предстоит работать. Необходимо задать больщое количество вопросов, чтобы узнать, каковой должна быть структура базы данных.

Предположим, что нужен столбец для хранения информации по прогнозируемому количеству осадков . Это будет число? Или это можно представить частично-цифровым форматом, т.е. довольно часто, но не всегда закодированное как число? Достаточно вспомнить, например, как при объявлении прогноза погоды, всегда называется ожидаемая мера. Иногда это число ( 25 сантиметров осадков ), но иногда это укладывается в простую, достаточно размытую формулировку ( незначительные осадки ). Это нормально для прогноза погоды, но как быть с такими данными в базе данных? В этом случае необходим цифровой столбец для хранения числа, или строковые данные для хранения текстовой информации? Возможен комплексный подход, когда в двух столбцах будет храниться числовое значение для первого случая и текстовый столбец для хранения текстовой информации во втором случае. При этом обязательно будет заполнен один из этих столбцов, а второй - будет пустым. Может показаться, что соверщенно очевидно, что такой ситуации по возможности следует избегать. Это ухудщит читабельность таблицы и затруднит создание запросов.

Попытаемся хранить все строки в цифровой форме, а затем преобразовывать их при выводе на печать. Например, любое ненулевое значение ожидаемой величины, меньще 0,01 см, можно отобразить как отслеживаемое число:

SELECT IF(precip>0 AND precip<.01, trace, precip) FROM ....

При денежных расчетах вы работаете со значениями, которые включают доллары и центы. Их можно представить в формате с плавающей точкой, но типы FLOAT И DOUBLE Подвергаются округлению и могут не удовлетворить по точности. Люди очень щепетильны в денежных вопросах, и поэтому потребуется тип, обладающий исключительной точностью. В распоряжении у разработчика базы данных будет несколько вариантов рещений.

Деньги можно представить типом DECIMAL (М, 2) выбрав при этом такое значение М, которое бы полностью удовлетворяло диапазону необходимых значений. Это будут значения с плавающей точкой и без десятичной части. Преимущество типа DECIMAL (М, 2) заключается в том, что значения хранятся в виде строки и не подвергаются округлению. Недостаток в следующем - операции со строками менее эффективны, чем операции со значениями, внутренне представленными числами.

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

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

Высоту и рост можно привести в качестве другого примера данных, которые можно представить разными способами.

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

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

Одно цифровое поле для хранения высоты в дюймах. Это наиболее удобное представление для базы данных, но самое трудное для восприятия человека. При отображении данные могут быть представлены в формате, отличном от формата, в котором они хранятся в базе данных. Данные можно переформатировать в более понятную форму, используя различные функции СУБД MySQL. Это может оказаться наиболее удобным вариантом хранения информации о росте или высоте.

Еще одна проблема. Если хранится информация о дате, включают ли эти данные информацию о времени, т.е. будут ли они вообще содержать информацию о времени? СУБД MySQL не имеет типа данных, имеющего факультативную временную часть: тип DATE не хранит информации о времени, а DATETIME должен содержать информацию о времени. Это

6-1729

значит, что если информация о времени может отсутствовать, дату можно хранить в столбце типа date, а время - в time. При этом столбец time будет объявлен с параметром null:

CREATE TABLE my table (

date DATE NOT NULL,

time TIME NULL

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

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

В этом случае необходимо четко определить, можно ли ограничиться одной датой или понадобятся как дата, так и время проведения опыта. Это зависит от того, проводится ли опыт над одним и тем же предметом несколько раз в день. Если да, то сохраняем время (скажем, момент начала опыта) в столбец типа datetime или отдельно date и time. Без данных о времени будет невозможно отличить один опыт от другого, особенно если в день проводится несколько опытов над одним объектом.

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

Этого можно было избежать, добавив столбец tike в таблицу. Данные о времени проведения опытов можно взять из источника независимой информации (например, из протоколов, зафиксированных на бумаге). К сожалению, эта процедура очень трудоемка, но другого способа устранения неоднозначности не существует. Даже если существует источник независимой информации, это не поможет полностью устранить неоднозначность и приведет к ошибкам в работе уже написанной профаммы, обрабатывающей информацию из таблиц. Так что всегда лучше объяснить проблему заказчику и предпринять все возможное на этапе проектирования базы данных.

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