×
Мы обрабатываем cookies, чтобы сделать наш сайт удобнее и персонализированнее для вас. Подробнее: политика использования «cookies» и «политики конфиденциальности».

Для самостоятельной настройки ознакомьтесь с инструкцией

Дополнительные настройки cookies в браузерах

Файлы cookie автоматически загружаются в ваш браузер при посещении веб-сайта. У вас есть возможность управлять этими файлами. Если Вы не согласны с использованием файлов cookies, запретите их сохранение на своём устройстве, удалите уже имеющиеся файлы cookies через настройки браузера или прекратите использование сайта.

При отключении обработки cookie наш сайт продолжит функционировать, однако будут использоваться исключительно необходимые технические файлы, без которых работа ресурса невозможна.

Инструкция по отключению cookies
Принять
Настроить
Отклонить

ДОКУМЕНТАЦИЯ

Выберите версию, форк и язык для СУБД Digital Q.DataBase, чтобы прочитать или скачать всю документацию.
Техподдержка
Документация
Диасофт
Авторские права © 2016–2025 ООО "Диасофт Экосистема"
Скачать всю документацию:

6.1.83. CREATE TABLE

Примечания

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 расширением.

Наверх
свяжитесь
с нами
контакты
Для прямой связи с нами вы можете использовать контакты ниже, либо оставить заявку через форму обратной связи, и мы обязательно свяжемся с вами

*поля обязательные к заполнению