Основные типы данных PostgreSQL

типы данных PostgreSQLДо этого момента разговор о типах данных PostgreSQL велся в общих словах (см. вот этот мой блог). Из схемы видно, что использованные типы (далеко не все из имею­щихся в PostgreSQL) - это скорее базовые типы, известные средству проектирования, которые могут быть преобразованы в реальные типы данных PostgreSQL при создании реальных таблиц.

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

 

Поскольку необходимость введения дополнительного уникального столбца встречается при проектировании баз данных повсеместно, су­ществует и встроенное решение, новый тип данных SERIAL. Этот специ­альный тип представляет собой целое число, автоматически увеличи­вающееся при добавлении строки в таблицу и устанавливающее новое уникальное значение при добавлении каждой строки. Если новая стро­ка вводится в таблицу, имеющую столбец типа SERIAL, не нужно указывать никакого значения для этого столбца, СУБД сама автоматичес­ки присвоит следующее значение.

В большинстве баз данных при присваивании последовательных вели­чин удаленные строки не учитываются. Присваиваемое число просто увеличивается для каждой новой строки. Средство проектирования, с помощью которого были выполнены представленные выше диаграм­мы, показывает поля типа SERIAL как INTEGER, потому что этот тип яв­ляется базовым.

 

Тип данных Описание

INTEGER

Целое число.

SERIAL

 Целое число, автоматически устанавливаемое в уникальную ве­личину для каждой добавляемой строки. На рисунках это не от­ражено, но именно этот тип будет использоваться для столбцов «_id».

CHAR

 

Символьный массив фиксированного размера, размер указыва­ется в скобках после названия типа. В столбцах данного типа PostgreSQL всегда будет сохранять ровно указанное количество символов. Если CHAR(256) служит для хранения одного символа, в базе данных будет занято как минимум 256 байт, которые и бу­дут возвращены при извлечении данных.

VARCHAR

 

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

DATE

 

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

NUMERIC

Возможность хранить числа с указанным количеством разрядов (первое число в скобках) и фиксированным количеством разря­дов после запятой (второе число в скобках). Так, NUMERIC(7,2) со­хранит ровно семь разрядов, два из них - после запятой.

 

Далее в моем блоге будут рассмотрены и другие типы данных PostgreSQL, при этом окажется, что какие-то из них больше подходят для хране­ния денежных значений, чем NUMERIC, поскольку несмотря на то, что использовать NUMERIC весьма удобно, это не самый эффективный способ хранения чисел с плавающей запятой в PostgreSQL.


Значение NULL

Новичков в теории баз данных может смутить такое понятие, как NULL. В терминах баз данных NULL обычно означает, что величина не извест­на (хотя существуют еще одна-две разновидности определения с едва уловимыми отличиями).

Посмотрим на таблицу orderinfo, в ней содержится столбец дат заказа, а также столбец дат отгрузки, оба имеют тип DATE. Как следует посту­пить, если заказ уже получен, но еще не отправлен? Что сохранить в столбце дат отгрузки? Можно сохранить специальную дату, сигналь­ную величину (sentinel value), которая указывала бы, что заказ еще не отправлен. В системах UNIX можно использовать в качестве такой да­ты 1 января 1970 года, т. к. именно с этого дня системы UNIX ведут свой отсчет. В любом случае эта дата должна предшествовать дате соз­дания базы данных, тогда будет очевидно, что дата специальная, в на­шем же случае она будет иметь смысл «еще не отправлено».

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

К счастью, во всех реляционных базах данных существует специаль­ная величина под названием NULL, которая обычно означает «в настоя­щий момент неизвестно». Обратите внимание, что это не ноль, не пус­тая строка и не нечто, что могло бы быть представлено в поле некоторо­го типа. «Неизвестное» очень сильно отличается от 0 и пустой строки.

Чрезвычайно важно присматривать за такими величинами, потому что они могут появляться в произвольных местах, причиняя неудоб­ства. В таблице orderinfo можно установить дату отправки в NULL (до того, как заказ отгружен), значение «в настоящий момент неизвест­но» полностью соответствует нашей ситуации.

Существует и несколько другое значение NULL (оно не так распростра­нено, как первое) - «не относится» (not relevant) к данной строке. Предположим, например, что проводится опрос группы людей, при этом один из вопросов касается цвета очков. Но для тех, кто очки не носит, этот вопрос, естественно, не имеет никакого смысла. В таком случае можно использовать NULL в соответствующем столбце, для того чтобы показать, что информация не имеет отношения к данной кон­кретной строке.

 

Проверка на NULL

Одним из свойств NULL является следующее: при сравнении двух значе­ний NULL результатом всегда будет «не равны». Это может удивить, но подумайте, ведь NULL - это неизвестное, поэтому абсолютно логично, что при сравнении двух неизвестных оказывается, что они не равны.

В SQL предоставлена специальная возможность проверки величин на значение NULL, если необходимо найти их и проверить, то задается во­прос 'IS NULL'.

Поведение величин NULL может иметь свои особенности, поэтому при проектировании таблицы можно указать, что в некоторых столбцах не могут храниться NULL. Обычно удобно бывает сказать, что для столбцов будет выполняться условие NOT NULL', - для уверенности в том, что NULL там не появится (например, в столбце, представляющем собой первичный ключ). Некоторые проектировщики баз данных пропаган­дируют практически полную отмену использования величин NULL, но все же в них есть и определенная польза. Поэтому, как правило, под­держивается применение величин NULL в отдельных столбцах при на­личии реальной потребности в значениях, которые не определены.

Вас заинтересует / Intresting for you:

Устанавливать или обновлять Po...
Устанавливать или обновлять Po... 475 просмотров Максим Николенко Sun, 12 Aug 2018, 11:07:20
Установка PostgreSQL из дистри...
Установка PostgreSQL из дистри... 808 просмотров Tarcoola Ningae Sun, 19 Aug 2018, 12:02:39
Установка PostgreSQL 10.5 из и...
Установка PostgreSQL 10.5 из и... 671 просмотров Tarcoola Ningae Sun, 19 Aug 2018, 11:45:55