Программирование >>  Sql: полное руководство 

1 ... 21 22 23 [ 24 ] 25 26 27 ... 264


в качестве примера рассмотрим форматы представления даты и времени в различных СУБД. Например, в DB2 существует сразу три типа данных:

date - представляет дату, например June 30, 1990 ;

time - представляет время суток, например 12:30 P.M. ;

timestamp - представляет конкретный момент времени с точностью до наносекунд.

Значения даты и времени можно представлять в виде строковых констант. Кроме того, поддерживаются арифметические операции над значениями даты. Ниже приведен пример допустимого запроса для СУБД DB2, в котором предполагается, что в столбце hire date Содержатся данные типа date:

SELECT NAME, HIRE DATE EROM SALESREPS WHERE HIRE DATE >= 05/30/1990 + 15 DAYS

В СУБД SQL Server имеется единый тип данных для представления даты и времени - datetime, который напоминает тип данных timestamp из DB2. Если бы столбец hire date имел тип datetime, в этой СУБД можно было бы выполнить такой запрос:

SELECT NAME, HIRE DATE 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 NAjfe HIRE DATE FROM SALESREPS WHERE HIRE DATE >= DATEADD(DAY, 15, 05/30/1990)

Это, конечно же, значительно отличается от синтаксиса DB2.

СУБД Oracle также поддерживает единственный тип данных для представления даты и времени, который называется date. Как и тип данных datetime в SQL Sener, тип данных date в Oracle фактически соответствует типу данных timestamp из DB2. Аналогично SQL Server, временная часть значения типа date по умолчанию принимается равной полуночи. Формат даты, принятый в Oracle по умолчанию, отличается от форматов, принятых в DB2 и SQL Server, поэтому версия запроса для Oracle имеет следующий вид:



SELECT NAME, HIRE DATE FROM SALESREPS WHERE HIRE DATE >= 14-JUN-90

СУБД Oracle также, хотя и с некоторыми офаничениями, поддерживает арифметические операции над датами, поэтому запрос из DB2 можно представить в виде:

SELECT NAME, HIRE DATE FROM SALESREPS WHERE HIRE DATE >= 30-MAY-90 + 15

В конце концов, в стандарт SQL2 был введен набор типов данных для работы с датой и временем, основанных на рассмотренных типах данных из DB2, но не идентичных им. Помимо типов date, time и timestamp, появился Также тип interval,

предназначенный для хранения значений интервалов времени. В стандарте определены четкие принципы выполнения арифметических операций над значениями даты и времени, принципы задания точности вычисления интервалов времени, учета разницы между часовыми поясами и т.д.

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

Константы

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

INSERT INTO SALESREPS (EMPL NUM, NAME, QUOTA, HIRE DATE, SALES) VALUES (115, Dennis Irving, 17500,0.00, 21-JUN-90, 0.00)

Здесь в предложении values определено значение для каждого столбца в новой строке. Константы используются также в выражениях, как в приведенной ниже инструкции select:

SELECT CIT?\ FROM OFFICES WHERE TARGET > (1.1 * SALES) + 10000.0

в стандарте ANSI/ISO определен формат числовых и строковых констант, или литералов, которые представляют конкретные значения данных. Этот формат используется в большинстве СУБД.



Числовые константы

Целые и десятичные константы (известные также под названием точных числовых литералов) в инструкциях SQL представляются в виде обычных десятичных чисел с необязательным знаком плюс (+) или минус (-) перед ними:

21 -375 2000.00 +497500.8778

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

$0.75 $5000.00 $-567.89

Константы с плавающей запятой (известные также по.!;и1азванием приблизительных числовых литералов) определяются с помощью символа Е и имеют такой же формат, как и в большинстве языков программирования. Ниже приведены примеры констант с плавающей запятой:

1.5ЕЗ -3.14159Е1 2.5Е-7 0.783926Е21

Символ Е читается как умножить на десять в степени , так что первая константа представляет число 1,5 умножить на десять в степени 3 , или 1500.

Строковые константы

в соответствии со стандартом ANSI/ISO строковые константы в SQL должны быть заключены в одинарные кавычки, как показано в следующих примерах:

Jones, John J. New York Western

Если необходимо включить в строковую константу одинарную кавычку, вместо нее следует поставить две одинарные кавычки. Таким образом, следующая константа:

I сапt

представляет строку 1 cant .

В некоторых СУБД, например в SQL Server и Informix, строковые константы можно заключать в двойные кавычки:

Jones, John J. New York Western

К сожалению, употребление двойных кавычек вызывает проблемы при переносе программ в другие СУБД. В частности, СУБД SQL/DS, вопреки стандарту ANSI/ISO, позволяет использовать в именах столбцов пробелы и другие специальные символы При использовании в инструкции SQL эти имена необходимо заключать в двойные кавычки. Например, если бы столбец name таблицы salesreps был в СУБД SQL/DS переименован в full name, то для этой СУБД была бы допустима следующая инструкция:

SELECT, -ftJbbJAME , SALES, QUOTA FROM SALESRE>S WHERE FULL NAME = Jones John J.



1 ... 21 22 23 [ 24 ] 25 26 27 ... 264

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика