Проблемы переносимости (миф о переносимости) Появление стандарта SQL вызвало довольно много восторженных заявлений о переносимости SQL и использующих его приложений. Часто говорят, что любое приложение, используя SQL, может работать с любой СУБД. На самом деле пробелы в стандарте SQL-89 и различия между существующими диалектами SQL достаточно значительны, и при переводе приложения под другую СУБД его всегда приходится модифицировать.
Эти отличия, большинство из которых устранено в стандарте SQL2, но не в коммерческих продуктах, включают в себя:
• Коды ошибок. В стандарте SQL-89 не определены коды, возвращаемые инструкциями SQL при возникновении ошибок, и в каждой из коммерческих реализаций используется собственный набор таких кодов. В стандарте SQL2 определены стандартные коды ошибок.
• Типы данных. В стандарте SQL-89 определен минимальный набор типов данных, однако в нем отсутствуют некоторые из наиболее распространенных и полезных типов, например символьные строки переменной длины, дата и время, а также денежные единицы. В стандарте SQL2 упомянуты эти типы данных, однако отсутствуют "новые" типы данных, такие как графические и мультимедийные объекты.
• Системные таблицы. В стандарте SQL-89 умалчивается о системных таблицах, в которых содержится информация о структуре самой базы данных. Поэтому каждый поставщик создавал собственные системные таблицы, и их структура отличается даже в четырех реализациях SQL компании IBM. Системные таблицы стандартизированы в SQL2, но только на верхних уровнях совместимости, которые еще не реализованы в большинстве СУБД.
• Интерактивный SQL. В стандарте SQL-89 определен только программный SQL, используемый в приложениях. Например, инструкция SELECT, предназначенная для выполнения запросов к базе данных в интерактивном режиме, в стандарте отсутствует.
• Программный интерфейс. В первом стандарте определен абстрактный способ использования SQL в приложениях, написанных на таких языках программирования, как COBOL, С, FORTRAN и др. Этот способ не реализован ни в одном коммерческом продукте, а в существующих программных интерфейсах имеются значительные отличия. В стандарте SQL2 определен интерфейс встроенного SQL для популярных языков программирования, но не интерфейс вызовов функций.
• Динамический SQL. В стандарте SQL-89 не описаны элементы SQL, необходимые для разработки приложений общего назначения, таких как генераторы отчетов и программы создания запросов. Однако эти элементы, известные под названием динамический SQL, имеются почти во всех СУБД и в различных системах значительно отличаются. В SQL2 входит стандарт динамического SQL, но он еще не реализован большинством разработчиков СУБД, вынужденных учитывать наличие сотен тысяч существующих приложений.
• Семантические отличия. Поскольку некоторые элементы определены в стандартах как зависящие от реализации, может возникнуть ситуация, когда в результате выполнения одного и того же запроса в двух совместимых СУБД будут получены два различных набора результатов. Отличия результатов обусловлены различиями в обработке значений NULL, разными статистическими функциями и несовпадением процедур удаления повторяющихся строк.
• Порядок сортировки. В стандарте SQL-89 не упоминается порядок сортировки символов, хранящихся в базе данных. Результаты запроса с сортировкой будут отличаться при выполнении этого запроса на персональном компьютере (с кодировкой ASCII) и на мэйнфрейме (с кодировкой EBCDIC). Стандарт SQL2 включает расширенную спецификацию того, как программа или пользователь могут запрашивать требуемый порядок сортировки, но это касается только верхнего уровня совместимости, который еще не реализован в большинстве СУБД.
• Структура базы данных. В стандарте SQL-89 определен SQL, который используется уже после того, как база данных была открыта и подготовлена к работе. Детали наименования баз данных и первоначального подключения к ним сильно отличаются и несовместимы. Стандарт SQL2 в некоторой степени унифицирует этот процесс, но не может полностью ликвидировать все отличия.
Вопреки перечисленным различиям, в начале 90-х годов стали появляться коммерческие программы, реализующие переносимость приложений между различными СУБД. Однако в таких программах для каждой из поддерживаемых СУБД требуется специальный конвертер, который генерирует код в соответствии с определенным диалектом SQL, выполняет преобразование типов данных, транслирует коды ошибок и т.д. "Прозрачная" переносимость между различными реляционными СУБД является основной целью стандарта SQL2 и протокола ODBC, и на этом пути достигнут значительный успех. Сегодня существуют стандартные "драйверы" ODBC, реализующие доступ к ведущим СУБД.
SQL и сети
Рост популярности компьютерных сетей оказал большое влияние на управление базами данных и придал SQL новые возможности. По мере распространения сетей приложения, которые раньше работали на центральном мини-компьютере или мэйнфрейме, переводятся на серверы и рабочие станции ЛВС. В таких сетях SQL играет важнейшую роль и связывает приложение, выполняющееся на рабочей станции, и СУБД, управляющую совместно используемыми данными на сервере. Недавний взрыв популярности Internet и WWW еще больше усилил влияние SQL в сфере сетевых технологий. С появлением трехуровневой архитектуры Internet язык SQL стал связующим звеном между управляющим приложением (второй уровень — сервер приложений или Web-сервер) и сервером баз данных (третий уровень). В следующих параграфах мы поговорим о развитии архитектур сетевого управления базами данных и о роли, которую SQL играет в каждой из них.
Инструкции
В SQL существует приблизительно сорок инструкций. Каждая из них ''просит" СУБД выполнить определенное действие, например извлечь данные, создать таблицу или добавить в таблицу новые данные.
Каждая инструкция SQL начинается с команды, т.е. ключевого слова, описывающего действие, выполняемое инструкцией. Типичными командами являются create (создать), insert (добавить), delete (удалить) и commit (зафиксировать). После команды идет одно или несколько предложений. Предложение описывает данные, с которыми работает инструкция, или содержит уточняющую информацию о действии, выполняемом инструкцией. Каждое предложение также начинается с ключевого слова, такого как where (где), from (откуда), into (куда) и having (имеющий). Одни предложения в инструкции являются обязательными, а другие — нет. Конкретная структура и содержимое предложения могут изменяться. Многие предложения содержат имена таблиц или столбцов; некоторые из них могут содержать дополнительные ключевые слова, константы и выражения.
В стандарте ANSI/ISO определены ключевые слова, которые применяются в качестве команд и в предложениях инструкций. В соответствии со стандартом эти ключевые слова нельзя использовать для именования объектов базы данных, таких как таблицы, столбцы и пользователи. Во многих СУБД этот запрет ослаблен, однако следует избегать использования ключевых слов в качестве имен таблиц и столбцов. В табл. 5.2 перечислены ключевые слова, включенные в стандарт SQL2. Их почти в три раза больше, чем в SQL1. В стандарте SQL2 определен также список "потенциальных" ключевых слов, которые могут стать таковыми в будущих версиях стандарта (табл. 5.3).
Имена
У каждого объекта в базе данных есть уникальное имя. Имена используются в инструкциях SQL и указывают, над каким объектом базы данных инструкция должна выполнить действие. Основными именованными объектами в реляционной базе данных являются таблицы, столбцы и пользователи; правила их именования были определены еще в стандарте SQL1. В стандарте SQL2 этот список значительно расширен и включает схемы (коллекции таблиц), ограничения (ограничительные условия, накладываемые на содержимое таблиц и их отношения), домены (допустимые наборы значений, которые могут быть занесены в столбец) и ряд других объектов. Во многих СУБД существуют дополнительные виды именованных объектов, например хранимые процедуры (Sybase и SQL Server), отношения "первичный ключ — внешний ключ" (DB2) и формы для ввода данных (Ingres).
В соответствии со стандартом ANSI/ISO имена в SQL должны содержать от 1 до 18 символов, начинаться с буквы и не содержать пробелов или специальных символов пунктуации. В стандарте SQL2 максимальное число символов в имени увеличено до 128. На практике поддержка имен в различных СУБД реализована по-разному. В DB2, к примеру, имена пользователей не могут превышать 8 символов, но имена таблиц и столбцов могут быть более длинными. Кроме того, в различных СУБД существуют разные подходы к использованию в именах таблиц специальных символов. Поэтому для повышения переносимости лучше делать имена сравнительно короткими и избегать употребления в них специальных символов.
Имена таблиц
Если в инструкции указано имя таблицы, СУБД предполагает, что происходит обращение к одной из ваших собственных таблиц (т.е. таблиц, которые создали вы). Обычно таблицам присваиваются короткие, но описательные имена. В небольших базах данных, предназначенных для личного или группового использования, выбор имен зависит от разработчика базы данных. В более крупных, корпоративных базах данных могут существовать определенные корпоративные стандарты именования таблиц, позволяющие избежать конфликтов имен.
Большинство СУБД позволяют различным пользователям создавать таблицы с одинаковыми именами. Имея соответствующее разрешение, можно обращаться к таблицам, владельцами которых являются другие пользователи, с помощью полного имени таблицы. Оно состоит из имени владельца таблицы и собственно ее имени, разделенных точкой. Например, полное имя таблицы birthdays, владельцем которой является пользователь по имени sam, имеет следующий вид:
SAM.BIRTHDAYS
Полное имя таблицы можно использовать вместо короткого имени во всех инструкциях SQL.
Стандарт SQL2 еще больше обобщает понятие полного имени таблицы. Он разрешает создавать именованное множество таблиц, называемое схемой. Для доступа к таблице в схеме также применяется полное имя. Например, обращение к таблице birthdays, помещенной в схему employeeinfo, записывается так:
EMPLOYEEINFO.BIRTHDAYS
Имена столбцов
Если в инструкции задается имя столбца, СУБД сама определяет, в какой из указанных в этой же инструкции таблиц содержится данный столбец. Однако если в инструкцию требуется включить два столбца из различных таблиц, но с одинаковыми именами, необходимо указать полные имена столбцов, которые однозначно определяют их местонахождение. Полное имя столбца состоит из имени таблицы, содержащей столбец, и имени столбца (короткого имени), разделенных точкой. Например, полное имя столбца sales из таблицы salesreps имеет следующий вид:
SALESREPS.SALES
Если столбец находится в таблице, владельцем которой является другой пользователь, то в полном имени столбца следует указывать полное имя таблицы. Например, полное имя столбца вirth_date в таблице birthdays, владельцем которой является пользователь SAM, имеет следующий вид:
SAM.BIRTHDAYS.BIRTH_DATE
Полное имя столбца можно использовать вместо короткого имени во всех инструкциях SQL; об исключениях говорится при описании конкретных инструкций.
Контрольные вопросы
1. Стандарт SQL и переносимость приложений.
2. Перечислите основные проблемы переносимости.
3. Сформулируйте правила формирования имен объектов в SQL.
Лекция 3
Общее описание типов данных
В стандарте SQL1 был описан лишь минимальный набор типов данных, которые можно использовать для представления информации в реляционной базе данных. Они поддерживаются во всех коммерческих СУБД. Стандарт SQL2 добавил в этот список строки переменной длины, значения даты и времени и др. Современные СУБД позволяют обрабатывать данные самых разнообразных типов, среди которых наиболее распространенными являются:
• Целые числа. В столбцах, имеющих этот тип данных, обычно хранятся данные о ценах, количествах, возрасте сотрудников и т.д. Целочисленные столбцы часто используются также для хранения идентификаторов, таких как идентификатор клиента, служащего или заказа.
• Десятичные числа. В столбцах данного типа хранятся числа, имеющие дробную часть, но которые необходимо вычислять точно, например курсы валют и проценты. Кроме того, в таких столбцах часто хранятся денежные величины.
• Числа с плавающей запятой. Столбцы этого типа используются для хранения величин, которые можно вычислять приблизительно, например значения весов и расстояний. Числа с плавающей запятой могут представлять больший диапазон значений, чем десятичные числа, однако при вычислениях возможны погрешности округления.
• Строки символов постоянной длины. В столбцах, имеющих этот тип данных, обычно хранятся имена людей и компаний, адреса и т.п.
• Строки символов переменной длины. Столбцы этого типа позволяют хранить строки символов, длина которых изменяется в некотором диапазоне. В стандарте SQL1 были определены только строки постоянной длины, которые проще обрабатывать, но они требуют больше места для хранения.
Денежные величины. Во многих СУБД поддерживается тип данных money или CURRENCY, который обычно хранится в виде десятичного числа или числа с плавающей запятой. Наличие отдельного типа данных для представления денежных величин позволяет правильно форматировать их при выводе на экран.
Дата и время. Поддержка значений даты/времени также широко распространена в различных СУБД, хотя способы ее реализации довольно сильно отличаются друг от друга. Как правило, над значениями этого типа данных можно выполнять различные операции. Стандарт SQL2 включает определение типов данных date, time, timestamp и interval, а также поддержку часовых поясов и возможность указания точности представления времени (например, десятые или сотые доли секунды).
Булевы величины. Некоторые СУБД, например Informix Universal Server, явным образом поддерживают логические значения (TRUE или false), а другие СУБД разрешают выполнять в инструкциях SQL логические операции (сравнение, логическое И/ИЛИ и др.) над данными.
Длинный текст. Многие СУБД поддерживают столбцы, в которых хранятся длинные текстовые строки (обычно длиной до 32000 или 65000 символов, а в некоторых случаях и больше). Это позволяет хранить в базе данных целые документы. Как правило, СУБД запрещает использовать эти столбцы в интерактивных запросах.
Неструктурированные потоки байтов. Современные СУБД позволяют хранить и извлекать неструктурированные потоки байтов переменной длины. Столбцы, имеющие этот тип данных, обычно используются для хранения графических и видеоизображений, исполняемых файлов и других неструктурированных данных. К примеру, тип данных image в SQL Server позволяет хранить потоки данных размером до 2 миллиардов байтов.
Азиатские символы. В последнее время все больше поставщиков СУБД стали включать в свои продукты поддержку строк переменной и постоянной длины, содержащих символы азиатских алфавитов. Однако над такими строками, как правило, нельзя выполнять операции поиска и сортировки. В табл. 5.4 перечислены типы данных, определенные в стандарте ANSI/ISO.
Типы данных, появившиеся в SQL2
Различия в поддержке типов данных в разных СУБД существенно препятствуют переносимости приложений, в которых используется SQL. Причины подобных различий следует искать в самом пути, по которому развивались реляционные базы данных.
Вот типичная схема:
• Поставщик СУБД добавил в свой продукт поддержку нового типа данных, который обеспечивает новые полезные возможности для определенной группы пользователей.
• Другой поставщик, оценив идею, ввел поддержку того же типа данных, но с небольшими модификациями, чтобы его нельзя было обвинить в слепом копировании.
• Если идея оказалась удачной, то по прошествии нескольких лет рассматриваемый тип данных появляется в большинстве ведущих СУБД, став частью "джентльменского набора" базовых типов данных.
• Далее этой идеей начинают интересоваться комитеты по стандартизации, чьей задачей является устранение произвольных различий в реализации идеи в ведущих СУБД. Но чем больше таких различий, тем труднее найти компромисс. Как правило, результатом деятельности комитета является вариант, который несоответствует ни одной из реализаций.
• Поставщики СУБД начинают внедрять поддержку полученного стандартизированного типа данных, но поскольку они располагают обширной базой уже инсталлированных продуктов, то вынуждены сопровождать и старый вариант типа данных.
• По прошествии длительного периода времени (обычно включающего выпуск нескольких новых версий СУБД) пользователи, наконец, полностью переходят к использованию стандартного варианта рассматриваемого типа данных, и поставщик СУБД начинает процесс исключения поддержки старого варианта из своего продукта.
В качестве примера рассмотрим форматы представления даты и времени в различных СУБД. Например, в DB2 существует сразу три типа данных:
• date — представляет дату, например "June 30, 1990";
• TIME — представляет время суток, например ''12:30 P.M.";
• timestamp — представляет конкретный момент времени с точностью до наносекунд.
Значения даты и времени можно представлять в виде строковых констант. Кроме того, поддерживаются арифметические операции над значениями даты. Ниже приведен пример допустимого запроса для СУБД DB2, в котором предполагается, что в столбце hire_date содержатся данные типа date:
SELECT NAME, HIRE_DATE
FROM SALESREPS WHERE HIRE_DATE >= '05/30/1990' + 15 DAYS
В СУБД SQL Server имеется единый тип данных для представления даты и времени — datetime, который напоминает тип данных timestamp из DB2. Если бы столбец hire_date имел тип datetime, в этой СУБД можно было бы выполнить такой запрос:
SELECT NAME, HIREJDATE
FROM SALESREPS WHERE HIRE_DATE >= '06/14/1990'
Поскольку в запросе не указано конкретное время, SQL Server по умолчанию примет, что время соответствует полуночи. Таким образом, запрос для SQL Server в действительности означает:
SELECT NAME, HIRE_DATE
FROM SALESREPS WHERE HIRE_DATE >= '06/14/1990 12:00AM’
Если информация о дате приема служащего на работу была сохранена в базе данных в полдень 14 июня 1990 года, то строка, содержащая сведения об этом человеке, не попадет в результаты запроса в SQL Server, однако попадет в результаты запроса в DB2 (поскольку эта СУБД оперировала бы только датой). Кроме того, SQL Server поддерживает арифметические операции над датами с помощью набора встроенных функций. Так, рассматривавшийся выше запрос из DB2 можно переписать для SQL Server следующим образом:
SELECT NAME^ HIRE_DATE
FROM SALESREPS WHERE HIRE__DATE >= DATEADD(DAY, 15, '05/30/1990')
Это, конечно же, значительно отличается от синтаксиса DB2.
СУБД Oracle также поддерживает единственный тип данных для представления даты и времени, который называется date. Как и тип данных datetime в SQLServer, тип данных date в Oracle фактически соответствует типу данных time stamp из DB2. Аналогично SQL Server, временная часть значения типа date по умолчанию принимается равной полуночи. Формат даты, принятый в Oracle по умолчанию, отличается от форматов, принятых в DB2 и SQL Server.
Типы данных
В языке SQL/89 поддерживаются следующие типы данных: CHARACTER, NUMERIC, DECIMAL,INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION. Эти типы данных классифицируются на типы строк символов, точных чисел и приблизительных чисел. К первому классу относится CHARACTER. Спецификатор типа имеет вид CHARACTER (lenght), где lenght задает длину строк данного типа. Заметим, что в SQL/89 нет типа строк переменного размера, хотя во многих реализациях они допускаются. Литеральные строки символов изображаются в виде 'последовательность символов' (например, 'example'). Представителями второго класса типов являются NUMERIC, DECIMAL (или DEC), INTEGER (или INT) и SMALLINT. Спецификатор типа NUMERIC имеет вид NUMERIC [(precision [, scale]). Специфицируются точные числа, представляемые с точностью precision и масштабом scale. Здесь и далее, если опущен масштаб, то он полагается равным 0, а если опущена точность, то ее значение по умолчанию определяется в реализации.
Спецификатор типа DECIMAL (или DEC) имеет вид NUMERIC [(precision [, scale]). Специфицируются точные числа, представленные с масштабом scale и точностью, равной или большей значения precision. INTEGER специфицирует тип данных точных чисел с масштабом 0 и определяемой в реализации точностью. SMALLINT специфицирует тип данных точных чисел с масштабом 0 и определяемой в реализации точностью, не большей, чем точность чисел типа INTEGER. Литеральные значения точных чисел в общем случае представляются в форме
[+|-] <целое-без-знака> [.<целое-без-знака>].
Наконец, в классу типов данных приблизительных чисел относятся типы FLOAT, REAL и DOUBLE PRECISION. Спецификатор типа FLOAT имеет вид FLOAT [(precision)]. Специфицируются приблизительные числа с двоичной точностью, равной или большей значения precision.
REAL специфицирует тип данных приблизительных чисел с точностью, определенной в реализации. DOUBLE PRECISION специфицирует тип данных приблизительных чисел с точностью, определенной в реализации, большей, чем точность типа REAL. Литеральные значения приблизительных чисел в общем случае представляются в виде
<литеральное-значение-точного-числа> E <целое-со-знаком>.
Заметим, что хотя с использованием языка SQL можно определить схему БД, содержащую данные любого из перечисленных типов, возможность использования этих данных в прикладных системах зависит от применяемого языка программирования. Весь набор типов данных можно использовать, только если программировать на ПЛ/1. Поэтому в некоторых реализациях SQL типы данных с масштабом и точностью вообще не поддерживаются.
Хотя правила встраивания SQL в программы на языке Си не определены в SQL/89, в большинстве реализаций, поддерживающих такое встраивание, имеется следующее соответствие между типами данных SQL и типами данных Си: CHARACTER соответствует строкам Си; INTEGER соответствует long; SMALLINT соответствует short; REAL соответствует float; DOUBLE PRECISION соответствует double(именно такое соответствие утверждено в стандарте SQL/92).
Заметим еще, что в большинстве реализаций SQL поддерживаются некоторые дополнительные типы данных, например, DATE, TIME, INTERVAL, MONEY. Некоторые из этих типов специфицированы в стандарте SQL/92, но в текущих реализациях синтаксические и семантические свойства таких типов могут различаться.
В качестве примера практической реализации стандарта, рассмотрим типы данных поддерживаемых СУБД SQL Anywhere.
В SQL Anywhere типы хранимых данных можно объединить в следующие категории :
Символьные типы данных: для хранения строк символов и цифр .
Типы данных Character
CHAR [ ( max-length ) ]
| CHARACTER [ ( max-length ) ]
| CHARACTER VARYING [ ( max-length ) ]
| LONG VARCHAR
| VARCHAR [ ( max-length ) ]
Описание
CHAR [(max-length)] Символьные данные с длиной не превышающей max-length. Если max-length не указана, по умолчанию принимается 1. Максимальное значение 32,767.
CHARACTER [(max-length)] Тоже что CHAR[(max-length)].
VARCHAR [(max-length)] Тоже что CHAR[(max-length)].
CHARACTER VARYING[(max-length)] Тоже что CHAR[(max-length)].
LONG VARCHAR Символьные данные произвольной длины. Максимальный размер ограничен размером файла базы данных (2GB для версии 5.5).
Числовые типы данных - для хранения числовых данных.
Типы данных Numeric
DECIMAL [ ( длина [ , точность ] ) ]
| DOUBLE
| FLOAT [ (длина ) ]
| INT
| INTEGER
| NUMERIC [ (длина [ , точность ] ) ]
| REAL
| SMALLINT
Описание
INT Целое число со знаком максимальное значение 2,147,483,647 занимает 4 байта.
INTEGER Тоже что INT.
SMALLINT Целое число со знаком максимальное значение 32,767 занимает 2 байта.
DECIMAL [ ( длина [ , точность ] )] Десятичное число из <длина> цифр и <точность> - число знаков после десятичной точки. Значения по умолчанию <точность> = 6 and <длина> = 30.
Количество требуемой памяти можно вычислить по формуле:
2 + int( (before+1) / 2 ) + int( (after+1)/2 )
NUMERIC [ (длина [ , точность ] ) ] Тоже что DECIMAL.
FLOAT [ ( длина ) ] Если длина не указана, тип дынных FLOAT аналогичен типу REAL. Если <длина> указана, тип FLOAT аналогичен REAL или DOUBLE , в зависимости от значения <длины>.
Тип FLOAT поддерживается на всех платформах. Типы REAL и DOUBLE зависят от реализации .
DOUBLE занимает 8 байт. Диапазон значений от 2.22507385850720160e-308 до 1.79769313486231560e+308. Точность DOUBLE до 15 значащих цифр.
REAL Занимает 4 байта. Диапазон значений от 1.175494351e-38 до 3.402823466e+38. Точность REAL до 6 значащих цифр.
Типы данных для хранения даты и времени.
Типы данных Date и time
DATE
| TIME
| TIMESTAMP
Описание:
DATE – предназначен для хранения календарной даты. Значение года может быть от 0001 до 9999. Тип DATE требует 4 байта.
TIMESTAMP – “момент времени” – содержит год, месяц, день, час, минуты, секунды и доли секунд. Тип DATE требует 8 байт памяти.
Типы данных Binary data
Бинарные(Двоичные) типы данных - для хранения двоичных данных, таких как изображения, документы и другие данные которые не интерпретируются СУБД(передаются пользователю только как единое целое для обработки).
BINARY [ ( max-length ) ]
| LONG BINARY
Описание
BINARY [(max-length)] Бинарные данные длиной не более max-length (в байтах). Если размер не указан, по умолчанию принимается 1. Максимально допустимый размер 32767. Тип BINARY аналогичен типу CHAR исключая операции сравнения.
LONG BINARY Двоичные данные произвольной длины. Максимальный размер ограничен размером файла БД (2 GB для файловой системы файл).
Тип данных, определенные пользователем (User-defined)
Типы данных определенные пользователем (иногда называемые доменами).
Являются псевдонимами для встроенных типов данных, включая длину и количество знаков после запятой (длину символьного выражения и тд). Дополнительно могут быть указаны DEFAULT -значения условия проверки CHECK. (И ограничения NOT Null)
Создаются оператором Create datatype.
Пример: создается тип данных street_address, который является символьными строками длиной 35 символов.
CREATE DATATYPE street_address CHAR( 35 )
Созданный тип данных может использоваться также как все встроенные типы данных.
Для удаления пользовательского типа данных используется оператор DROP DATATYPE :
DROP DATATYPE street_address
Контрольные вопросы
1. Типы данных поддерживаемые в различных стандартах SQL.
2. Перечислите числовые типы данных.
3. Перечислите типы данных для хранения символьных строк.
4. Типы данных для хранения календарных дат и времени.
Лекция 4
|