Postgresql автоинкрементное поле

PostgreSQL AUTO INCREMENT

Простые и составные ключи

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

Если таблица не имеет единственного уникального поля, первичный ключ может быть составлен из нескольких полей, совокупность значений которых гарантирует уникальность. Так, имя, фамилия, отчество, номер паспорта, серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в таблице, содержащей записи о людях, первичным ключом может быть набор полей, состоящий из типа личного документа, его серии и номера. Такой первичный ключ называют составным ключом (англ. compound key, composite key, concatenated key).

Первичный ключ может состоять из информационных полей таблицы (то есть полей, содержащих полезную информацию об описываемых объектах). Такой первичный ключ называют естественным ключом. Теоретически, естественный ключ всегда можно сформировать, в этом случае мы получим т. н. интеллектуальный ключ. На практике, однако, использование естественных ключей наталкивается на определённые сложности:

  • Низкая эффективность — Естественный ключ может быть велик по размеру (особенно когда он составной), и его использование окажется технически неэффективным (ведь во всех таблицах, связанных с данной, понадобится создать поле того же размера, чтобы хранить ссылки).
  • Необходимость каскадных изменений — При изменении значения поля, входящего в естественный ключ, оказывается необходимым изменить значение поля не только в данной таблице, но и во всех таблицах, связанных с данной, в противном случае все ссылки на данную запись окажутся некорректными. В сложных базах данных таких связанных таблиц может быть очень много, и всегда остаётся опасность упустить из виду какую-то из них. При добавлении новых связанных таблиц приходится добавлять согласующие изменения во все места программ, где правится исходная таблица.
  • Несоответствие реальности — Уникальность естественного первичного ключа в реальных БД не всегда соблюдается. Допустим, например, что первичный ключ в таблице — данные личного документа. В такую таблицу окажется невозможным внести человека, о документах которого нет информации в момент добавления записи, а на практике такая необходимость может возникнуть.
  • Повторяемость — При использовании естественного ключа, содержание может повторяться (так, как могут повторятся поля, из которых состоит ключ), что недопустимо в первичном ключе

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

⇐ Предыдущая3456789101112Следующая ⇒


Дата добавления: 2015-05-09; Просмотров: 161; Нарушение авторских прав?;




Читайте также:

Продолжение темы, начатой этим сообщением и посвященной автоинкрементальным полям.

В отличие от MySQL, в таблицах PostgreSQL автоинкрементальных полей может быть несколько. Для создания таких полей используются последовательности – .

– автоматический счётчик, для которого можно задавать начальное значение, конечное значение, шаг прироста, тип прироста (плюс, умножить и т.д.).

PostgreSQL: Миграция с MySQL — как сделать поле auto increment

Этот счётчик можно привязать к полю – полю будет присваиваться значение счетчика (если при вставке пользователь не определил значение поля), а счетчик будет автоматом наращиваться.

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

  1. создается последовательность с именем tblname_colname_seq;
  2. тип поля меняется с на ;
  3. в модификаторы поля добавляется конструкция .

Если нужно сделать автоинкрементальным поле уже существующей таблицы, то сперва нужно создать последовательность:

а затем изменить модификатор поля:

10.04.2009 15:01 Дмитрий в рубрике sql . Темы: postgresql, sql, шпаргалка | Комментарии

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

Усложнение структуры базы данных вполне закономерно. Предположим, что сущность имеет интеллектуальный ключ, но помимо него был введён ещё и суррогатный ключ. Ввод дополнительного атрибута в каждую таблицу сам по себе усложняет структуру базы данных. Но, чтобы не нарушать 3НФ (о чём говорилось ранее) и ограничения предметной области необходимо поддерживать уникальность и интеллектуального, и суррогатного ключей одновременно. Соответственно, количество структур, с помощью которых поддерживается уникальность (как правило, уникальных индексов), увеличивается. И так по каждому отношению, обладающему интеллектуальным ключом.

Усложнение логики базы данных не столь очевидно и на этом вопросе стоит остановиться более подробно. Интеллектуальный ключ, являясь внешним ключом, содержит полезную информацию, и эта информация может быть использована в рамках ссылочного отношения, содержащего данный внешний ключ. Например, есть общероссийский классификатор товаров, где каждый вид товаров или товарная группа (классификатор имеет иерархическое строение) обладают уникальным номером. Предположим, что у нас есть отношение, которое фиксирует только продуктовые товары, ссылаясь при этом на общероссийский классификатор. При использовании интеллектуального внешнего ключа можно на поле внешнего ключа наложить дополнительное ограничение диапазона значений. Теперь проектировщики могут быть спокойны за то, что в отношение продуктовых товаров не попадёт иной товар, поскольку код другого товара будет вне диапазона значений, отведённого для продуктовых товаров. То есть, при попытке ввода товара, не относящегося к продуктовой группе, произойдёт нарушение ограничения наложенного на внешний ключ. Можно ли сделать подобное ограничение на суррогатных ключах? Нет, без введения дополнительных механизмов, нельзя, и вот почему. При создании отношения «Продуктовые товары» ещё не известно, какие значения будут присвоены суррогатному ключу у тех или иных категорий товаров, и, тем более, неизвестно будут ли продуктовые товары представлены диапазоном значений или некоторой произвольной последовательностью номеров, так, что между номерами продуктовых товаров окажутся номера совсем иных товаров.

PostgreSQL — AUTO INCREMENT

Как следствие, в случае использования суррогатных ключей придётся реализовывать какие-то сложные логические конструкции, которые бы поддерживали достоверность данных в отношении «Продуктовые товары».

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

TABLE COEFFICIENTS (     COEF DECIMAL(8.2) NOT NULL PRIMARY KEY,     DESCRIPTION VARCHAR(255) NOT NULL,     …); TABLE NODES (     PART_NO CHAR(15) NOT NULL PRIMARY KEY,     COEF DECIMAL(8.2) NOT NULL REFERENCES COEFFICIENTS,     FIELD_A INTEGER NOT NULL,     FIELD_B DECIMAL(9.5) NOT NULL,     … CHECK ((FIELD_A * COEF) < FIELD_B),     ...);

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

Автоинкрементные поля в PostgreSQL

T-SQL 2012: Первичные, внешние ключи, ограничения, уникальность


—Перви́чный ключ(primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).
—Перви́чный ключ — столбец, значения которого во всех строках различны. 
—В таблице возможно наличие только одного ограничения по первичному ключу.
—Все столбцы с ограничением PRIMARY KEY должны иметь признак NOT NULL. 
—Если допустимость значения NULL не указана, то для всех столбцов c ограничением PRIMARY KEY устанавливается признак NOT NULL.

USE tsql;

—Создание первичного ключа в новой таблице
CREATE TABLE dbo.keys
(
   ID int NOT NULL,
   name VARCHAR(MAX),
   email VARCHAR(MAX)
   CONSTRAINT PK_T_ID PRIMARY KEY CLUSTERED (ID)
);

—Создание первичного ключа в существующей таблице
ALTER TABLE dbo.keys
ADD CONSTRAINT PK_T_ID PRIMARY KEY CLUSTERED (ID);

—Можно создать ограничение уникальности чтобы гарантировать, что в определенных столбцах, не участвующих в первичном ключе, не будут встречаться повторяющиеся значения. 
—Создание ограничения уникальности автоматически приводит к созданию соответствующего уникального индекса.

—Создание ограничения уникальности
CREATE TABLE dbo.un
(
   UN int NOT NULL,
   name VARCHAR(MAX),
   email VARCHAR(MAX)
   CONSTRAINT AK_UN UNIQUE(UN),
);

—Создание ограничения уникальности в существующей таблице
ALTER TABLE dbo.un
ADD CONSTRAINT AK_UN UNIQUE (UN); 

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

—Создание внешнего ключа в новой таблице
—Предложения ON DELETE CASCADE и ON UPDATE CASCADE обеспечевают распространение изменений, вносимых в таблицу dbo.keys на таблицу dbo.fk.

CREATE TABLE dbo.fk 
(
    TID int NOT NULL, 
    name VARCHAR(MAX),
    email VARCHAR(MAX)
CONSTRAINT PK_T_TID PRIMARY KEY NONCLUSTERED(TID), 
CONSTRAINT FK_T_TID FOREIGN KEY(TID) 
    REFERENCES dbo.keys(ID)
    ON DELETE CASCADE
    ON UPDATE CASCADE
);

—Создание внешнего ключа в существующей таблице
ALTER TABLE dbo.fk 
ADD CONSTRAINT FK_T_TID FOREIGN KEY(TID) 
    REFERENCES dbo.keys(ID) 
    ON DELETE CASCADE
    ON UPDATE CASCADE
;

—Проверим работу CASCADE
insert into dbo.keys values (1, '1', '1')
insert into dbo.fk values (1, '1', '1')

UPDATE dbo.keys SET ID = 7 WHERE id = 1
SELECT * FROM dbo.fk

DELETE dbo.keys WHERE ID = 7
SELECT * FROM dbo.fk

—Создание ограничений
CREATE TABLE dbo.ch
(
    i int
    CONSTRAINT chi CHECK (i >= 1)
);

—Создание ограничений в созданной таблице
ALTER TABLE dbo.ch
ADD CONSTRAINT chi CHECK (i >= 1);

—Проверим работу ограничения
insert into dbo.ch values (1)
insert into dbo.ch values (-1)


Комментарии пользователей

Анонимам нельзя оставоять комментарии, зарегистрируйтесь!

Добавить комментарий

Закрыть меню