Digital Q.DataBase автоматически создает индекс для каждого ограничения уникальности и ограничения первичного ключа для обеспечения уникальности. Таким образом, создавать индекс для столбцов первичного ключа в явном виде не требуется. (См. CREATE INDEX для получения дополнительной информации.)
В текущей реализации ограничения уникальности и первичные ключи не наследуются. Это делает сочетание наследования и ограничений уникальности практически неработоспособным.
Таблица не может содержать более 1600 столбцов. (На практике фактический лимит обычно ниже из-за ограничений на длину кортежа.)
Создание таблицы films и таблицы
distributors:
CREATE TABLE films (
code char(5) CONSTRAINT firstkey PRIMARY KEY,
title varchar(40) NOT NULL,
did integer NOT NULL,
date_prod date,
kind varchar(10),
len interval hour to minute
);
CREATE TABLE distributors (
did integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
name varchar(40) NOT NULL CHECK (name <> '')
);
Создание таблицы с двумерным массивом:
CREATE TABLE array_int (
vector int[][]
);
Определение уникального ограничения таблицы
films. Уникальные ограничения таблицы могут быть определены
для одного или нескольких столбцов таблицы:
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT production UNIQUE(date_prod)
);
Определение ограничения столбца CHECK:
CREATE TABLE distributors (
did integer CHECK (did > 100),
name varchar(40)
);
Определение ограничения таблицы CHECK:
CREATE TABLE distributors (
did integer,
name varchar(40),
CONSTRAINT con1 CHECK (did > 100 AND name <> '')
);
Определение ограничения таблицы «первичный ключ»
films:
CREATE TABLE films (
code char(5),
title varchar(40),
did integer,
date_prod date,
kind varchar(10),
len interval hour to minute,
CONSTRAINT code_title PRIMARY KEY(code,title)
);
Определение ограничения первичного ключа для таблицы
distributors. Следующие два примера эквивалентны: в первом используется синтаксис ограничения таблицы, во втором — синтаксис ограничения столбца:
CREATE TABLE distributors (
did integer,
name varchar(40),
PRIMARY KEY(did)
);
CREATE TABLE distributors (
did integer PRIMARY KEY,
name varchar(40)
);
Назначение литеральной константы в качестве значения по умолчанию для столбца
имя, определение значения по умолчанию для столбца
did генерироваться путем выбора следующего значения объекта последовательности, и установить значение по умолчанию
modtime равным времени вставки строки:
CREATE TABLE distributors (
name varchar(40) DEFAULT 'Luso Films',
did integer DEFAULT nextval('distributors_serial'),
modtime timestamp DEFAULT current_timestamp
);
Определение двух NOT NULL ограничений столбцов в таблице
distributors, одному из которых явно присвоено имя:
CREATE TABLE distributors (
did integer CONSTRAINT no_null NOT NULL,
name varchar(40) NOT NULL
);
Определение ограничения уникальности для имя столбец:
CREATE TABLE distributors (
did integer,
name varchar(40) UNIQUE
);
То же самое, но с определением в виде ограничения таблицы:
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name)
);
Создание той же таблицы с указанием коэффициента заполнения (fill factor) 70% как для самой таблицы, так и для её уникального индекса:
CREATE TABLE distributors (
did integer,
name varchar(40),
UNIQUE(name) WITH (fillfactor=70)
)
WITH (fillfactor=70);
Создание таблицы circles с ограничением исключения, предотвращающим пересечение любых двух окружностей:
CREATE TABLE circles (
c circle,
EXCLUDE USING gist (c WITH &&)
);
Создание таблицы cinemas в табличном пространстве diskvol1:
CREATE TABLE cinemas (
id serial,
name text,
location text
) TABLESPACE diskvol1;
Создание составного типа и типизированной таблицы:
CREATE TYPE employee_type AS (name text, salary numeric);
CREATE TABLE employees OF employee_type (
PRIMARY KEY (name),
salary WITH OPTIONS DEFAULT 1000
);
Создание таблицы, секционированной по диапазону:
CREATE TABLE measurement (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (logdate);
Создание таблицы, секционированной по диапазону, с несколькими столбцами в ключе секционирования:
CREATE TABLE measurement_year_month (
logdate date not null,
peaktemp int,
unitsales int
) PARTITION BY RANGE (EXTRACT(YEAR FROM logdate), EXTRACT(MONTH FROM logdate));
Создание таблицы, секционированной по списку:
CREATE TABLE cities (
city_id bigserial not null,
name text not null,
population bigint
) PARTITION BY LIST (left(lower(name), 1));
Создание таблицы, секционированной по хешу:
CREATE TABLE orders (
order_id bigint not null,
cust_id bigint not null,
status text
) PARTITION BY HASH (order_id);
Создание секции таблицы, секционированной по диапазону:
CREATE TABLE measurement_y2016m07
PARTITION OF measurement (
unitsales DEFAULT 0
) FOR VALUES FROM ('2016-07-01') TO ('2016-08-01');
Создание нескольких секций таблицы, секционированной по диапазону, с использованием нескольких столбцов в ключе секционирования:
CREATE TABLE measurement_ym_older
PARTITION OF measurement_year_month
FOR VALUES FROM (MINVALUE, MINVALUE) TO (2016, 11);
CREATE TABLE measurement_ym_y2016m11
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 11) TO (2016, 12);
CREATE TABLE measurement_ym_y2016m12
PARTITION OF measurement_year_month
FOR VALUES FROM (2016, 12) TO (2017, 01);
CREATE TABLE measurement_ym_y2017m01
PARTITION OF measurement_year_month
FOR VALUES FROM (2017, 01) TO (2017, 02);
Создание секции таблицы, секционированной по списку:
CREATE TABLE cities_ab
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b');
Создание секции таблицы, секционированной по списку, которая сама в свою очередь является секционированной, с последующим добавлением в неё секции:
CREATE TABLE cities_ab
PARTITION OF cities (
CONSTRAINT city_id_nonzero CHECK (city_id != 0)
) FOR VALUES IN ('a', 'b') PARTITION BY RANGE (population);
CREATE TABLE cities_ab_10000_to_100000
PARTITION OF cities_ab FOR VALUES FROM (10000) TO (100000);
Создание секций таблицы, секционированной по хешу:
CREATE TABLE orders_p1 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE orders_p2 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE orders_p3 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE orders_p4 PARTITION OF orders
FOR VALUES WITH (MODULUS 4, REMAINDER 3);
Создание раздела по умолчанию:
CREATE TABLE cities_partdef
PARTITION OF cities DEFAULT;
Команда CREATE TABLE соответствует
SQL с исключениями, перечисленными ниже.
Хотя синтаксис команды CREATE TEMPORARY TABLE
схож со стандартом SQL, результат их работы различается. Согласно стандарту, временные таблицы определяются только один раз и автоматически существуют (будучи изначально пустыми) в каждом сеансе, где они необходимы.
Digital Q.DataBase вместо этого требует,
чтобы каждый сеанс вызывал собственную команду CREATE TEMPORARY
TABLE для каждой используемой временной таблицы. Это позволяет различным сеансам использовать одно и то же имя временной таблицы для разных целей, в то время как стандарт предписывает, чтобы все экземпляры временной таблицы с данным именем имели одинаковую структуру.
Стандартное определение поведения временных таблиц повсеместно игнорируется. Digital Q.DataBaseповедение 's в данном аспекте аналогично поведению некоторых других баз данных SQL.
Стандарт SQL также различает глобальные и локальные временные таблицы, где локальная временная таблица имеет отдельный набор строк для каждого модуля SQL в рамках каждого сеанса, хотя ее определение является общим для всех сеансов. Поскольку Digital Q.DataBase не поддерживает модули SQL, это различие не актуально для Digital Q.DataBase.
Для обеспечения совместимости Digital Q.DataBase будет
принимать GLOBAL и LOCAL ключевые слова
в объявлении временной таблицы, но в настоящее время они не учитываются.
Использование этих ключевых слов не рекомендуется, так как в будущих версиях
Digital Q.DataBase может быть реализована интерпретация их значения, более соответствующая стандарту SQL.
Это ON COMMIT предложение для временных таблиц
также схоже со стандартом SQL, но имеет некоторые отличия.
Если ON COMMIT предложение опущено, стандарт SQL определяет поведение по умолчанию как ON COMMIT DELETE ROWS. Однако
поведением по умолчанию в Digital Q.DataBase является
ON COMMIT PRESERVE ROWS. The ON COMMIT
DROP опция отсутствует в стандарте SQL.
Если UNIQUE или PRIMARY KEY ограничение
не является откладываемым, Digital Q.DataBase проверка уникальности выполняется немедленно при каждой вставке или изменении строки. Стандарт SQL определяет, что уникальность должна проверяться только в конце выполнения инструкции; это имеет значение в тех случаях, когда, например, одна команда обновляет несколько значений ключа. Для обеспечения поведения, соответствующего стандарту, следует объявить ограничение как
DEFERRABLE но не отложенное (т. е. INITIALLY
IMMEDIATE). Следует учитывать, что это может работать значительно медленнее, чем немедленная проверка уникальности.
Стандарт SQL определяет, что CHECK ограничения столбцов
могут ссылаться только на тот столбец, к которому они применяются; только CHECK
ограничения таблицы могут ссылаться на несколько столбцов.
Digital Q.DataBase не накладывает данного
ограничения; оно обрабатывает ограничения таблицы и столбца на проверку одинаково.
EXCLUDE Ограничение
Это EXCLUDE тип ограничения является
Digital Q.DataBase расширением.
Возможность указывать списки столбцов в действиях для внешнего ключа
SET DEFAULT и SET NULL является
Digital Q.DataBase расширением.
Это Digital Q.DataBase расширение, позволяющее ограничению внешнего ключа ссылаться на столбцы уникального индекса вместо столбцов первичного ключа или ограничения уникальности.
NULL «Ограничение»
Это NULL «ограничение» (фактически не являющееся
ограничением) представляет собой Digital Q.DataBase
расширение стандарта SQL, включенное для совместимости с некоторыми другими системами управления базами данных (а также для симметрии с NOT
NULL ограничением). Поскольку оно применяется по умолчанию для любого столбца, его использование избыточно.
Стандарт SQL определяет, что имена ограничений таблицы и домена должны быть уникальными в пределах схемы, содержащей данную таблицу или домен.
Digital Q.DataBase допускает больше свободы: требуется лишь, чтобы имена ограничений были уникальными среди ограничений, относящихся к конкретной таблице или домену. Однако эта дополнительная свобода не распространяется на ограничения на базе индексов (UNIQUE,
PRIMARY KEY, и EXCLUDE
ограничения), так как связанный индекс имеет то же имя, что и ограничение, а имена индексов должны быть уникальными среди всех отношений в пределах одной схемы.
В настоящее время Digital Q.DataBase вовсе не записывает имена для ограничений непустого значения (not-null), поэтому на них не распространяется требование уникальности. Это поведение может измениться в будущих выпусках.
Множественное наследование через предложение INHERITS является
расширением языка Digital Q.DataBase расширение языка. Стандарты SQL:1999 и более поздние определяют одиночное наследование с использованием иного синтаксиса и иной семантики. Наследование в стиле SQL:1999 пока не поддерживается
Digital Q.DataBase.
Digital Q.DataBase позволяет создавать таблицу без столбцов
(например, CREATE TABLE foo();). Данная возможность является расширением стандарта SQL, который не допускает существование таблиц без столбцов. Сами по себе таблицы без столбцов малополезны, однако их запрет создает специфические исключения для ALTER TABLE
DROP COLUMN, поэтому целесообразнее игнорировать данное ограничение спецификации.
Digital Q.DataBase позволяет таблице иметь более одного
столбца идентификации. Стандарт определяет, что таблица может иметь не более одного столбца идентификации. Данное правило смягчено главным образом для обеспечения большей гибкости при изменении схемы или выполнении миграций. Обратите внимание, что INSERT команда поддерживает только одно предложение переопределения (override clause), которое применяется ко всей инструкции, поэтому наличие нескольких столбцов идентификации с различным поведением полноценно не поддерживается.
Параметр STORED не является стандартным, но также используется в других реализациях SQL. Стандарт SQL не определяет способ хранения генерируемых столбцов.
LIKE Предложение
Хотя LIKE предложение существует в стандарте SQL, многие из
параметров, которые Digital Q.DataBase принимает для него, не входят в стандарт, а некоторые стандартные параметры не реализованы в Digital Q.DataBase.
WITH Предложение
Это WITH предложение является Digital Q.DataBase
расширением; параметры хранения не входят в стандарт.
Это Digital Q.DataBase концепция табличных пространств не является частью стандарта. Следовательно, предложения TABLESPACE
и USING INDEX TABLESPACE являются расширениями.
Типизированные таблицы реализуют подмножество стандарта SQL. Согласно стандарту, типизированная таблица содержит столбцы, соответствующие базовому составному типу, а также один дополнительный столбец, являющийся «самоссылающимся столбцом». Digital Q.DataBase не поддерживает самоссылающиеся столбцы явным образом.
PARTITION BY Предложение
Это PARTITION BY предложение представляет собой
Digital Q.DataBase расширением.
PARTITION OF Предложение
Это PARTITION OF предложение представляет собой
Digital Q.DataBase расширением.