Типы данных в SQL

Типы данных в SQL

Каждая колонка таблицы имеет тип. Как уже указывалось, типы данных SQL сходны с типами данных традиционных языков программирования. В то время как во многих языках определен самый минимум типов, необходимых для работы, в SQL для удобства пользователей определены дополнительные типы, такие как MONEY и DATE. Данные типа MONEY можно было бы хранить и как один из основных числовых типов данных, однако использование типа, специально учитывающего особенности денежных расчетов, повышает легкость использования SQL, которая является одной из главных его целей.

В главе 15 «Справочник по SQL» дается полное справочное руководство по типам SQL, поддерживаемым MySQL и mSQL. В таблице 6-1 дан сокращенный список, состоящий из наиболее употребительных типов, поддерживаемых в обоих языках.

Таблица 6-1. Наиболее употребительные типы, данных, поддерживаемые как MySQL, так и mSQL

Тип данных

Описание

INT Целое число. В MySQL INT может быть со знаком или без знака, в то время как mSQL имеет отдельный тип UINT для беззнаковых целых.

REAL Число с плавающей запятой. Этот тип допускает больший диапазон значений, чем INT, но не обладает его точностью.

TEXT(length) Символьная величина переменной длины. В mSQL значение length используется как предположение о том, какой длины будут хранимые строки. Можно сохранять и строки большей длины, но ценой потери производительности. В MySQL TEXT - лишь один из нескольких типов данных переменного размера.

DATE Стандартное значение даты. Хотя формат хранения даты различен в MySQL и mSQL, оба ядра могут использовать тип DATE для хранения произвольных дат, относящихся к прошлому, настоящему и будущему. Оба ядра правильно решают «проблему 2000».

TIME

Стандартное значение времени. Этот тип используется для хранения времени дня безотносительно какой-либо даты. При использовании вместе с датой позволяет хранить конкретную дату и время. В MySQL есть дополнительный тип DATETIME для совместного хранения даты и времени в одном поле.

CHAR(length)

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

«MySQL поддерживает атрибут UNSIGNED для всех числовых типов. Этот модификатор позволяет вводить в колонку только положительные (беззнаковые) числа. Беззнаковые поля имеют верхний предел значений вдвое больший, чем у соответствующих знаковых типов. Беззнаковый TINYINT - однобайтовый числовой тип MySQL - имеет диапазон от 0 до 255, а не от -127 до 127, как у своего знакового аналога.

Та и другая СУБД имеют больше типов, чем перечислено выше. Особенно большое число типов поддерживает MySQL. Однако на практике в основном используются перечисленные типы. В mSQL выбор типа данных сводится к выбору типа, наиболее близкого к данным, которые вы собираетесь хранить. Размер данных, которые вы собираетесь хранить, играет гораздо большую роль при разработке таблиц MySQL.

Числовые типы данных

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

Символьные типы

С символьными типами работать немного труднее. Вы должны подумать не только о максимальной и минимальной длине строки, но также о среднем размере, частоте отклонения от него и необходимости в индексировании. В данном контексте мы называем индексом поле или группу полей, в которых вы собираетесь осуществлять поиск — в основном, в предложении WHERE. Индексирование, однако, значительно сложнее, чем такое упрощенное определение, и мы займемся им далее в этой главе. Здесь важно лишь отметить, что индексирование по символьным полям происходит значительно быстрее, если они имеют фиксированную длину. В действительности, mSQL даже не позволяет индексировать поля переменной длины. Если длина строк не слишком колеблется или, что еще лучше, постоянна, то, вероятно, лучше выбрать для поля тип CHAR. Пример хорошего кандидата на тип CHAR — код страны. Стандартом ISO определены двухсимвольные коды для всех стран (US для США, FR для Франции и т. д.). Поскольку эти коды состоят ровно из двух символов, CHAR(2) будет правильным выбором для данного поля.

Чтобы подходить для типа CHAR, поле необязательно должно быть фиксированной длины, но длина не должна сильно колебаться. Телефонные номера, к примеру, можно смело хранить в поле CHAR(13), хотя длина номеров различна в разных странах. Просто различие не столь велико, поэтому нет смысла делать поле для номера телефона переменным по длине. В отношении поля типа CHAR важно помнить, что, вне зависимости от реальной длины хранимой строки, в поле будет ровно столько символов, сколько указано в его размере — не больше и не меньше. Разность в длине между размером сохраняемого текста и размером поля заполняется пробелами. Не стоит беспокоиться по поводу нескольких лишних символов при хранении телефонных номеров, но не хотелось бы тратить много места в некоторых других случаях. Для этого существуют текстовые поля переменной длины.

Хороший пример поля, для которого требуется тип данных с переменной длиной, дает URL Интернет. По большей части адреса Web занимают сравнительно немного места - http://www.ora.com, http:// www.hughes.com.au, http://www.mysql.com - и не представляют проблемы. Иногда, однако, можно наткнуться на адреса подобного вида: http://www.winespectator.com/Wine/Spectator/ _notes\5527293926834323221480431354? Xvl I =&Xr5=&Xvl =& type-region-search- code=&Xal 4=flora+springs&Xv4=.

Если создать поле типа CHAR длины, достаточной для хранения этого URL, то почти для каждого другого хранимого URL будет напрасно тратиться весьма значительное пространство. Поля переменной длины позволяют задать такую длину, что оказывается возможным хранение необычно длинных значений, и в то же время не расходуется напрасно место при хранении обычных коротких величин. В MySQL и mSQL подход к этой проблеме различный.

Поля переменной длины в MySQL

Если вы используете только mSQL, этот раздел можно пропустить. Преимуществом текстовых полей переменной длины в MySQL является то, что они используют ровно столько места, сколько необходимо для хранения отдельной величины. Например, поле типа VARCHAR(255), в котором хранится строка «hello, world», занимает только двенадцать байтов (по одному байту на каждый символ плюс еще один байт для хранения длины).

В отличие от стандарта ANSI, в MySQL поля типа VARCHAR не дополняются пробелами. Перед записью из строки удаляются лишние пробелы.

Сохранить строки, длина которых больше, чем заданный размер поля, нельзя. В поле VARCHAR(4) можно сохранить строку не длиннее 4 символов. Если вы попытаетесь сохранить строку «happy birthday», MySQL сократит ее до «happ». Недостатком подхода MySQL к хранению полей переменной длины, в сравнении с mSQL, является то, что не существует способа сохранить необычную строку, длина которой превосходит заданное вами значение. В таблице 6-2 показан размер пространства, необходимого для хранения 144-символьного URL, продемонстрированного выше, и обычного, 30-символьного URL,

Таблица 6-2. Пространство памяти, необходимое для различных символьных типов MySQL

Тип данных

Пространство для хранения строки из 144 символов

Пространство для хранения строки из 30 символов

Максимальная длина строки

СНАR(150)

VARCHAR(ISO)

TINYTEXT(ISO)

ТЕХТ(150)

MEDIUM-ТЕХТ(150)

LONGTEXT(150)

Если через годы работы со своей базой данных вы обнаружите, что мир изменился, и поле, уютно чувствовавшее себя в типе VARCHAR(25), должно теперь вмещать строки длиной 30 символов, не все потеряно. В MySQL есть команда ALTER TABLE, позволяющая переопределить размер поля без потери данных.

ALTER TABLE mytable MODIFY tnycolumn LONGTEXT

Поля переменной длины в mSQL

Если вас интересует только MySQL, этот раздел можно пропустить. Символьные поля переменной длины в mSQL позволяют задать длину как средний размер строки, которая будет в нем храниться. Каждая величина, вводимая в это поле, займет, по крайней мере, столько места, сколько вами задано, но поле может хранить и более длинные строки. Для этого база данных создает таблицу переполнения, в которой хранит лишние данные. Недостаток такого подхода проявляется в снижении производительности и невозможности индексировать поля переменной длины.

Остановимся немного на последствиях различий в подходе. Чтобы сохранить все вышеперечисленные URL в поле типа CHAR, потребуется колонка типа CHAR(144). При таком развитии событий четыре упомянутые URL займут 576 байт (144 х 4), хотя фактически хранится только 216 байт данных. Остальные 360 байт- просто потерянное пространство. Если помножить эту цифру на тысячи и миллионы строк, то можно понять, что это представляет собой серьезную проблему. Если же использовать поле переменной длины типа ТЕХТ(30), то для хранения 216 байт данных требуется только 234 байта (30 X 3 + 144). Всего лишь 18 байт потеряно. Экономия составила 41%!

Двоичные типы данных

В mSQL нет поддержки двоичных данных. В MySQL, напротив, есть целый ряд двоичных типов данных, соответствующих своим символьным аналогам. Двоичными типами, поддерживаемыми MySQL, являются CHAR BINARY, VARCHAR BINARY, TINYBLOB, BLOB, MEDIUMBLOB и LONGBLOB. Практическое отличие между символьными типами и их двоичными аналогами основано на принципе кодировки. Двоичные данные просто являются куском данных, которые MySQL не пытается интерпретировать. Напротив, символьные данные предполагаются представляющими текстовые данные из используемых человеком алфавитов. Поэтому они кодируются и сортируются, основываясь на правилах, соответствующих рассматриваемому набору символов. Двоичные же данные MySQL сортирует в порядке ASCII без учета регистра.

Перечисления и множества

MySQL предоставляет еще два особых типа данных, не имеющих аналога в mSQL. Тип ENUM позволяет при создании таблицы указать список возможных значений некоторого поля. Например, если бы у вас была колонка с именем «фрукт», в которую вы разрешили бы помещать только значения «яблоко», «апельсин», «киви» и «банан», ей следовало бы присвоить тип ENUM:

CREATE TABLE meal(meal_id INT NOT NULL PRIMARY KEY,

фрукт ENUM('яблоко', 'апельсин', 'киви', 'банан'))

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

Тип MySQL SET работает аналогично, но позволяет одновременно хранить в поле несколько значений.

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

Любые мыслимые данные можно хранить с помощью числовых или символьных типов. В принципе, даже числа можно хранить в символьном виде. Однако то, что это можно сделать, не означает, что это нужно делать. Рассмотрим, к примеру, как хранить в базе данных денежные суммы. Можно делать это, используя INT или REAL. Хотя интуитивно REAL может показаться более подходящим - в конце концов, в денежных суммах нужны десятичные знаки, - на самом деле более правильно использовать INT. В полях, содержащих значения с плавающей запятой, таких как REAL, часто невозможно найти число с точным десятичным значением. Например, если вы вводите число 0.43, которое должно представлять сумму $0.43, MySQL и mSQL могут записать его как 0.42999998. Это небольшое отличие может вызвать проблемы при совершении большого числа математических операций. Сохраняя число как INT и устанавливая десятичную точку в нужное место, можно быть уверенным, что его значение представляет именно то, что вам требуется.

К чему такие хлопоты? Не лучше ли было бы, если бы MySQL и mSQL обеспечивали некий тип данных, специально предназначенный для денежных сумм? MySQL и в меньшей степени mSQL предоставляют специальные типы данных для таких случаев. Одним из них является тип MONEY, другим- DATE. Полное описание всех типов данных можно найти в главе 17 «Программы и утилиты для MySQL и mSQL».

14. Сетевая модель данных. Файл – сервер и клиент – сервер.

Сетевая модель данных

Типичным представителем систем, основанных на сетевой модели данных, является СУБД IDMS (Integrated Database Management System), разработанная компанией Cullinet Software, Inc. и изначально ориентированная на использования на мейнфреймах компании IBM. Архитектура системы основана на предложениях Data Base Task Group (DBTG) организации CODASYL (COnference on DAta SYstems Languages), которая отвечала за определение языка программирования COBOL. Отчет DBTG был опубликован в 1971 г., и вскоре после этого появилось несколько систем, поддерживающих архитектуру CODASYL, среди которых присутствовала и СУБД IDMS. В настоящее время IDMS принадлежит компании Computer Associates.

Сетевые структуры данных

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

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

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;

каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.

На формирование типов связи не накладываются особые ограничения; возможны, например, следующие ситуации:

тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии);

данный тип записи P может быть типом записи предка в любом числе типов связи;

данный тип записи P может быть типом записи потомка в любом числе типов связи;

может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться;

типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком – в другой;

предок и потомок могут быть одного типа записи.

На рис. 2.3 показан простой пример схемы сетевой БД. На этом рисунке показаны три типа записи: Отдел, Служащие и Руководитель и три типа связи: Состоит из служащих, Имеет руководителя и Является служащим. В типе связи Состоит из служащих типом записи-предком является Отдел, а типом записи-потомком – Служащие (экземпляр этого типа связи связывает экземпляр типа записи Отдел со многими экземплярами типа записи Служащие, соответствующими всем служащим данного отдела). В типе связи Имеет руководителя типом записи-предком является Отдел, а типом записи-потомком – Руководитель (экземпляр этого типа связи связывает экземпляр типа записи Отдел с одним экземпляром типа записи Руководитель, соответствующим руководителю данного отдела). Наконец, в типе связи Является служащим типом записи-предком является Руководитель, а типом записи-потомком – Служащие (экземпляр этого типа связи связывает экземпляр типа записи Руководитель с одним экземпляром типа записи Служащие, соответствующим тому служащему, которым является данный руководитель).

Базовые технологии обработки запросов в архитектурах файл-сервера и клиент-сервера

Прикладные программы управления данными представляют собой необходимый инструмент для распределенной обработки.

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

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

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

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

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

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

Прикладные программы баз данных клиент-сервера поддерживаются программными продуктами:

- NetWare Btrieve- программой управления записями с индексацией по ключу (выполняется на сервере);

- NetWare SQL - ядром реляционных баз данных, предназначенным для обеспечения системы защиты и целостности данных.

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

В настоящее время разработаны десятки тысяч прикладных автономных и многозадачных программ, ориентированных на клиента версий NetWare Btrieve, NetWare SQL, которые могут быть использованы организациями, создающими или имеющими сеть ЭВМ. Более того, версии NetWare Btrieve и NetWare SQL фирмы Novell для клиентов имеют согласованные API, что упрощает перенос программ из среды одного клиента в среду другого.

Файл-сервер Рабочая станция

Типовая среда обработки запросов в сетях ЭВМ.

б) Распределенная среда обработки запросов в сетях ЭВМ.

Рис. 4.11. (а,б).Технологии обработки запросов по базовым вариантам

По степени изменчивости все базы данных (БД) можно разделить на два класса:

А - условно-постоянные (в основном для справочных систем);

Б - сильно динамичные (для банковских, биржевых систем и т.п.).

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

Например,

- для условно-постоянных БД наиболее важными показателями являются показатели скорости отработки запросов и скорости формирования выходных отчетов по БД, а такие показатели, как скорость отработки транзакций и контроль целостности БД при отработке транзакций не столь критичны;

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

Поэтому любая СУБД не может одинаково успешно применяться при работе с БД разных классов. Такие системы, как CLIPPER, FOXPRO ориентированы на первый класс БД-(А), и здесь имеются неплохие результаты, а такие СУБД,как Informix, Ingres, SyBase создавались для второго класса-(Б).

Исходя из вышесказанного напрашивается вывод: найти "золотую середину", которая удовлетворяла бы требованиям обоих классов (А) и (Б). Решением этой противоречивой задачи является использование дифференциальной организации файлов базы данных, или дифференциальных файлов (ДФ).

В последнее время разработчики СУБД ведущих фирм подошли к использованию идеи ДФ. Причинами явились следующие факты:

- значительно расширился класс решаемых на IBM PC задач, так, что термин "персональный компьютер" уже не соответствует действительности;

- широкое распространение локальных вычислительных систем (ЛВС);

- разработка многопользовательских и многозадачных систем;

- стремительное развитие технической базы ЭВМ (в большей степени дисковой памяти).

Остановимся на сути ДФ применительно к БД в ЛВС. Реализация идеи ЛВС в различных СУБД значительно отличается.

Идея ДФ включает три положения:

- основной файл БД остается неизменным при любых обновлениях базы данных, т.е., любые изменения БД последовательно накапливаются в специальном файле изменений (не путать с журналом транзакций) - ДФ;

- никакие индексы для него не создаются и не поддерживаются.

Когда ДФ достигнет значительных размеров (примерно 25-40% от размеров БД), администратор вносит все изменения в основной файл БД в удобный момент времени в пакетном режиме.

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

Достоинства ДФ относятся к обеспечению высокой надежности, целостности БД и скорости отработки транзакций.

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

Что касается индексов, то проблемы их поддержания не существует (скорости добавления, удаления и модификации записей БД находятся на самом высоком уровне). Внесение добавлений в БД не отличается от добавлений в обычный последовательный файл. Время обновления записей БД не зависит ни от размеров БД, ни от длины ключей, ни от их числа. Временные затраты на блокировку (как одно из узких мест для БД и ЛВС) сведены к минимуму.

Для того, чтобы обеспечить согласованность данных по чтению нет необходимости блокировать целиком таблицу, что имеет место в ряде СУБД, т.е., когда запрос (или формируемый отчет) начинает выполняться, СУБД "запоминает" старший адрес в ДФ (моментальный снимок). При этом пользователь, инициализирующий свой запрос, не обязан ждать "своего момента". Он "не видит" никого из пользователей и получает снимок БД именно в этот момент времени. Далее, по мере выполнения запроса (даже очень быстрого) часть записей-целей могла быть или изменена или удалена. Это отразится только на старших адресах ДФ, а поэтому СУБД просто проигнорирует любые изменения данных, случившиеся после начала выполнения запроса. Гарантируется корректировка сложных и длительных запросов к БД, т.е. обеспечение согласованности по чтению и транзакциям.

Становится интересным вопрос, как в этом случае ведется поиск в БД. В этом случае по ассоциатору находится множество записей-целей: число и список их адресов в основной БД, после чего производится считывание "ассоциатора" ДФ и производится корректировка этого списка. За счет этой корректировки время поиска увеличивается, причем величина этого увеличения зависит от размеров ДФ. Своевременность обновления БД должна быть в компетенции администратора БД. Чтобы исключить существенные издержки, связанные с ДФ, можно накапливать изменения БД для их пакетной обработки и при поиске ДФ не учитывать. В ряде систем, таких как банковские, допускается потеря некоторой точности в период между циклами обновления - "контролируемое запаздывание".

Помимо всего прочего использование ДФ обеспечивает:

- возможность администратору восстанавливать случайно удаленные записи;

- возможность (при необходимости) хранить индексные файлы на самих рабочих станциях;

- возможность создания распределенных БД;

- одновременное выполнение транзакций.

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

Дата добавления: 2015-05-10