Визначення обмежень цілісності. Створення первинних ключів Первинний ключ в таблиці sql

Типи даних самі по собі обмежують безліч даних, які можна зберегти в таблиці. Однак для багатьох додатків такі обмеження занадто грубі. Наприклад, стовпець, що містить ціну продукту, повинен, ймовірно, приймати тільки позитивні значення. Але такого стандартного типу даних немає. Можливо, ви також захочете обмежити дані стовпця по відношенню до інших стовпцях або рядках. Наприклад, в таблиці з інформацією про товар має бути тільки один рядок з певним кодом товару.

Для вирішення подібних завдань SQL дозволяє вам визначати обмеження для стовпців і таблиць. Обмеження дають вам можливість керувати даними в таблицях так, як ви захочете. Якщо користувач спробує зберегти в стовпці значення, що порушує обмеження, виникне помилка. Обмеження діятимуть, навіть якщо це значення за замовчуванням.

5.3.1. Обмеження-перевірки

Обмеження-перевірка - найбільш загальний тип обмежень. У його визначенні ви можете вказати, що значення даного шпальти має задовольняти логічного виразу (перевірці істинності). Наприклад, ціну товару можна обмежити позитивними значеннями так:

Name text, price numeric CHECK (price\u003e 0) );

Як ви бачите, обмеження визначається після типу даних, як і значення за замовчуванням. Значення за замовчуванням і обмеження можуть зазначатися в будь-якому порядку. Обмеження-перевірка складається з ключового слова CHECK, за яким йде вираз в дужках. Цей вислів має включати стовпець, для якого задається обмеження, інакше воно не має великого сенсу.

Ви можете також привласнити обмеження окреме ім'я. Це поліпшить повідомлення про помилки і дозволить вам посилатися на це обмеження, коли вам знадобиться змінити його. Зробити це можна так:

CONSTRAINT positive_price CHECK (price\u003e 0));

Тобто, щоб створити іменоване обмеження, напишіть ключове слово CONSTRAINT, а за ним ідентифікатор і власне визначення обмеження. (Якщо ви не визначите ім'я обмеження таким чином, система вибере для нього ім'я за вас.)

Обмеження-перевірка може також посилатися на декілька стовпців. Наприклад, якщо ви зберігаєте звичайну ціну і ціну зі знижкою, так ви можете гарантувати, що ціна зі знижкою буде завжди менше звичайної:

CREATE TABLE products (product_no integer, name text, price numeric CHECK (price\u003e 0), discounted_price numeric CHECK (discounted_price\u003e 0), CHECK (price\u003e discounted_price) );

Перші два обмеження визначаються схожим чином, але для третього використовується новий синтаксис. Воно не пов'язане з певним стовпцем, а представлено окремим елементом в списку. Визначення стовпців і такі визначення обмежень можна переставляти в довільному порядку.

Про перші два обмеження можна сказати, що це обмеження стовпців, тоді як третя є обмеженням таблиці, так як воно написано окремо від визначень стовпців. Обмеження стовпців також можна записати в вигляді обмежень таблиці, тоді як зворотне не завжди можливо, тому що мається на увазі, що обмеження стовпця посилається тільки на пов'язаний стовпець. (Хоча Postgres Pro цього не вимагає, але для сумісності з іншими СУБД краще слідувати це правилом.) Раніше наведений приклад можна переписати і так:

CREATE TABLE products (product_no integer, name text, price numeric, CHECK (price\u003e 0), discounted_price numeric, CHECK (discounted_price\u003e 0), CHECK (price\u003e discounted_price));

Або навіть так:

CREATE TABLE products (product_no integer, name text, price numeric CHECK (price\u003e 0), discounted_price numeric, CHECK (discounted_price\u003e 0 AND price\u003e discounted_price));

Це справа смаку.

Обмеженням таблиці можна присвоювати імена так само, як і обмеженням стовпців:

CREATE TABLE products (product_no integer, name text, price numeric, CHECK (price\u003e 0), discounted_price numeric, CHECK (discounted_price\u003e 0), CONSTRAINT valid_discount CHECK (price\u003e discounted_price));

Слід зауважити, що обмеження-перевірка задовольняється, якщо вираз приймає значення true або NULL. Так як результатом багатьох виразів з операндами NULL буде значення NULL, такі обмеження не будуть перешкоджати записи NULL в пов'язані стовпці. Щоб гарантувати, що стовпець не містить значення NULL, можна використовувати обмеження NOT NULL, описане в наступному розділі.

5.3.2. Обмеження NOT NULL

Обмеження NOT NULL просто вказує, що колонки не можна присвоювати значення NULL. Приклад синтаксису:

CREATE TABLE products (product_no integer NOT NULL , Name text NOT NULL , Price numeric);

Обмеження NOT NULL завжди записується як обмеження стовпця і функціонально еквівалентно обмеження CHECK ( ім'я_стовпця IS NOT NULL), але в Postgres Pro явне обмеження NOT NULL працює більш ефективно. Хоча у такому записі є недолік - призначити ім'я таким обмеженням не можна.

Природно, для стовпця можна визначити більше одного обмеження. Для цього їх потрібно просто вказати одне за іншим:

CREATE TABLE products (product_no integer NOT NULL, name text NOT NULL, price numeric NOT NULL CHECK (price\u003e 0));

Порядок тут не має значення, він не обов'язково відповідає порядку перевірки обмежень.

Для обмеження NOT NULL є і зворотне: обмеження NULL. Воно не означає, що стовпець повинен мати тільки значення NULL, що звичайно було б безглуздо. Суть же його в простому вказівці, що стовпець може мати значення NULL (це поведінка за умовчанням). Обмеження NULL відсутній в стандарті SQL і використовувати його в переносите додатках не слід. (Воно було додано в Postgres Pro тільки для сумісності з деякими іншими СУБД.) Однак деякі користувачі люблять його використовувати, так як воно дозволяє легко перемикати обмеження в скрипті. Наприклад, ви можете почати з:

CREATE TABLE products (product_no integer NULL, name text NULL, price numeric NULL);

і потім вставити ключове слово NOT, де потрібно.

Підказка

При проектуванні баз даних найчастіше більшість стовпців повинні бути позначені як NOT NULL.

5.3.3. обмеження унікальності

Обмеження унікальності гарантують, що дані в певному стовпці або групі стовпців унікальні серед усіх рядків таблиці. Обмеження записується так:

CREATE TABLE products (product_no integer UNIQUE

у вигляді обмеження стовпця і так:

CREATE TABLE products (product_no integer, name text, price numeric, UNIQUE (product_no) );

у вигляді обмеження таблиці.

Щоб визначити обмеження унікальності для групи стовпців, запишіть його у вигляді обмеження таблиці, перерахувавши імена стовпців через кому:

UNIQUE (a, c) );

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

Ви можете призначити унікальному обмеження ім'я звичайним чином:

CREATE TABLE products (product_no integer CONSTRAINT must_be_different UNIQUE, name text, price numeric);

При додаванні обмеження унікальності буде автоматично створений унікальний індекс-B-дерево для стовпця або групи стовпців, перерахованих в обмеженні. Умова унікальності, що поширюється тільки на деякі рядки, не можна записати в вигляді обмеження унікальності, однак таку умову можна встановити, створивши унікальний частковий індекс.

Взагалі кажучи, обмеження унікальності порушується, якщо в таблиці виявляється кілька рядків, у яких збігаються значення всіх стовпців, включених в обмеження. Однак два значення NULL при порівнянні ніколи не вважаються рівними. Це означає, що навіть при наявності обмеження унікальності в таблиці можна зберегти рядки з дублюючими значеннями, якщо вони містять NULL в одному або декількох стовпцях обмеження. Це поведінка відповідає стандарту SQL, але ми чули про СУБД, які ведуть себе по-іншому. Майте на увазі цю особливість, розробляючи переносяться додатки.

5.3.4. первинні ключі

Обмеження первинного ключа означає, що утворює його стовпець або група стовпців може бути унікальним ідентифікатором рядків в таблиці. Для цього потрібно, щоб значення були одночасно унікальними і відмінними від NULL. Таким чином, таблиці з наступними двома визначеннями прийматимуть однакові дані:

CREATE TABLE products (product_no integer UNIQUE NOT NULL, name text, price numeric); CREATE TABLE products (product_no integer PRIMARY KEY , Name text, price numeric);

Первинні ключі можуть включати декілька стовпців; синтаксис схожий на запис обмежень унікальності:

CREATE TABLE example (a integer, b integer, c integer, PRIMARY KEY (a, c) );

При додаванні первинного ключа автоматично створюється унікальний індекс-B-дерево для стовпця або групи стовпців, перерахованих в первинному ключі, і дані стовпці позначаються як NOT NULL.

Таблиця може мати максимум один первинний ключ. (Обмежень унікальності і обмежень NOT NULL, які функціонально майже рівнозначні первинним ключам, може бути скільки завгодно, але призначити обмеженням первинного ключа можна тільки одне.) Теорія реляційних баз даних говорить, що первинний ключ повинен бути в кожній таблиці. У Postgres Pro такого жорсткого вимоги немає, але зазвичай краще йому слідувати.

Первинні ключі корисні і для документування, і для клієнтських додатків. Наприклад, графічного додатку з можливостями редагування вмісту таблиці, ймовірно, буде потрібно знати первинний ключ таблиці, щоб однозначно ідентифікувати її рядки. Первинні ключі знаходять і інше застосування в СУБД; зокрема, первинний ключ в таблиці визначає цільові стовпці за умовчанням для сторонніх ключів, які посилаються на цю таблицю.

5.3.5. зовнішні ключі

Обмеження зовнішнього ключа вказує, що значення стовпця (або групи стовпців) повинні відповідати значенням в деякій рядку інший таблиці. Це називається посилальної цілісністю двох пов'язаних таблиць.

Нехай у вас вже є таблиця продуктів, яку ми неодноразово використовували раніше:

CREATE TABLE products (product_no integer PRIMARY KEY, name text, price numeric);

Давайте припустимо, що у вас є таблиця із замовленнями цих продуктів. Ми хочемо, щоб в таблиці замовлень містилися тільки замовлення дійсно існуючих продуктів. Тому ми визначимо в ній обмеження зовнішнього ключа, що посилається на таблицю продуктів:

REFERENCES products (product_no) , Quantity integer);

З таким обмеженням створити замовлення зі значенням product_no, відсутнім в таблиці products (і не рівним NULL), буде неможливо.

У такій схемі таблицю orders називають підпорядкованої таблицею, а products - головною. Відповідно, стовпці називають так само підлеглим і головним (або посилаються і цільовим).

Попередню команду можна скоротити так:

CREATE TABLE orders (order_id integer PRIMARY KEY, product_no integer REFERENCES products , Quantity integer);

тобто, якщо опустити список стовпців, зовнішній ключ буде неявно пов'язаний з первинним ключем головної таблиці.

Зовнішній ключ також може посилатися на групу стовпців. В цьому випадку його потрібно записати у вигляді звичайного обмеження таблиці. наприклад:

CREATE TABLE t1 (a integer PRIMARY KEY, b integer, c integer, FOREIGN KEY (b, c) REFERENCES other_table (c1, c2) );

Природно, число і типи стовпців в обмеженні повинні відповідати числу і типам цільових стовпців.

Обмеження зовнішнього ключа можна призначити ім'я стандартним способом.

Таблиця може містити кілька обмежень зовнішнього ключа. Це корисно для зв'язку таблиць щодо многие-ко-многим. Скажімо, у вас є таблиці продуктів і замовлень, але ви хочете, щоб одне замовлення міг містити кілька продуктів (що неможливо в попередній схемі). Для цього ви можете використовувати таку схему:

CREATE TABLE products (product_no integer PRIMARY KEY, name text, price numeric); CREATE TABLE orders (order_id integer PRIMARY KEY, shipping_address text, ...); CREATE TABLE order_items (product_no integer REFERENCES products, order_id integer REFERENCES orders, quantity integer, PRIMARY KEY (product_no, order_id));

Зауважте, що в останній таблиці первинний ключ покриває зовнішні ключі.

Ми знаємо, що зовнішні ключі забороняють створення замовлень, що не відносяться ні до одного продукту. Але що робити, якщо після створення замовлень з певним продуктом ми захочемо видалити його? SQL впорається з цією ситуацією. Інтуїція підказує наступні варіанти поведінки:

Заборонити видалення продукту

Видалити також пов'язані замовлення

Щось ще?

Для ілюстрації давайте реалізуємо таких дій у вищенаведеному прикладі: при спробі вилучення продукту, на який посилаються замовлення (через таблицю order_items), ми забороняємо цю операцію. Якщо ж хтось спробує видалити замовлення, то віддалиться і його вміст:

CREATE TABLE products (product_no integer PRIMARY KEY, name text, price numeric); CREATE TABLE orders (order_id integer PRIMARY KEY, shipping_address text, ...); CREATE TABLE order_items (product_no integer REFERENCES products ON DELETE RESTRICT , Order_id integer REFERENCES orders ON DELETE CASCADE , Quantity integer, PRIMARY KEY (product_no, order_id));

Обмежують і каскадні видалення - два найбільш поширених варіанту. RESTRICT запобігає видалення пов'язаної рядки. NO ACTION означає, що якщо залежні рядки продовжують існувати при перевірці обмеження, виникає помилка (це поведінка за умовчанням). (Головною відмінністю цих двох варіантів є те, що NO ACTION дозволяє відкласти перевірку в процесі транзакції, а RESTRICT - немає.) CASCADE вказує, що при видаленні пов'язаних рядків залежні від них будуть так само автоматично видалені. Є ще два варіанти: SET NULL і SET DEFAULT. При видаленні пов'язаних рядків вони призначають залежним стовпцями в підпорядкованій таблиці значення NULL або значення за замовчуванням, відповідно. Зауважте, що це не буде підставою для порушення обмежень. Наприклад, якщо в якості дії задано SET DEFAULT, але значення за замовчуванням не задовольняє обмеження зовнішнього ключа, операція закінчиться помилкою.

Аналогічно вказівкою ON DELETE існує ON UPDATE, яке спрацьовує при зміні заданого стовпчика. При цьому можливі дії ті ж, а CASCADE в даному випадку означає, що змінені значення пов'язаних стовпців будуть скопійовані в залежні рядки.

Зазвичай залежна рядок не повинна задовольняти обмеження зовнішнього ключа, якщо один з пов'язаних стовпців містить NULL. Якщо в оголошення зовнішнього ключа додано MATCH FULL, рядок буде задовольняти обмеження, тільки якщо всі пов'язані стовпці рівні NULL (тобто при різних значеннях (NULL і не NULL) гарантується невиконання обмеження MATCH FULL). Якщо ви хочете, щоб залежні рядки не могли уникнути і цього обмеження, оголосіть пов'язані стовпці як NOT NULL.

Зовнішній ключ повинен посилатися на стовпці, що утворюють первинний ключ або обмеження унікальності. Таким чином, для пов'язаних стовпців завжди буде існувати індекс (визначений відповідним первинним ключем або обмеженням), а значить перевірки відповідності пов'язаної рядки будуть виконуватися ефективно. Так як команди DELETE для рядків головною таблиці або UPDATE для залежних стовпців зажадають просканувати підлеглу таблицю і знайти рядки, що посилаються на старі значення, корисно буде мати індекс і для підлеглих стовпців. Але це потрібно не завжди, і створити відповідний індекс можна по-різному, тому оголошення зовнішнього ключа не створює автоматично індекс по зв'язаних стовпчиках.

Останнє оновлення: 27.04.2019

Зовнішні ключі дозволяють встановити зв'язки між таблицями. Зовнішній ключ встановлюється для стовпців з залежною, підлеглої таблиці, і вказує на один із стовпців з головної таблиці. Як правило, зовнішній ключ вказує на первинний ключ з пов'язаної головної таблиці.

Загальний синтаксис установки зовнішнього ключа на рівні таблиці:

FOREIGN KEY (столбец1, столбец2, ... столбецN) REFERENCES главная_табліца (столбец_главной_табліци1, столбец_главной_табліци2, ... столбец_главной_табліциN)

Для створення обмеження зовнішнього ключа після FOREIGN KEY вказується стовпець таблиці, який буде представляє зовнішній ключ. А після ключового слова REFERENCES вказується ім'я пов'язаної таблиці, а потім в дужках ім'я пов'язаного стовпця, на який буде вказувати зовнішній ключ. Після висловлення REFERENCES йдуть вираження ON DELETE і ON UPDATE, які задають дію при видаленні і оновленні рядки з головної таблиці відповідно.

Наприклад, визначимо дві таблиці і зв'яжемо їх за допомогою зовнішнього ключа:

CREATE TABLE Customers (Id INT PRIMARY KEY AUTO_INCREMENT, Age INT, FirstName VARCHAR (20) NOT NULL, LastName VARCHAR (20) NOT NULL, Phone VARCHAR (20) NOT NULL UNIQUE); CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id));

В даному випадку визначені таблиці Customers і Orders. Customers є головною і представляє клієнта. Orders є залежною і являє замовлення, зроблене клієнтом. Таблиця Orders через стовпець CustomerId пов'язана з таблицею Customers і її стовпцем Id. Тобто стовпець CustomerId є зовнішнім ключем, який вказує на стовпець Id з таблиці Customers.

За допомогою оператора CONSTRAINT можна задати ім'я для обмеження зовнішнього ключа:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT orders_custonmers_fk FOREIGN KEY (CustomerId) REFERENCES Customers (Id));

ON DELETE і ON UPDATE

За допомогою виразів ON DELETE і ON UPDATE можна встановити дії, які виконуються відповідно при видаленні і зміні пов'язаної рядки з головної таблиці. Як дії можуть використовуватися такі опції:

CASCADE: автоматично видаляє або змінює рядки з залежною таблиці при видаленні або зміні пов'язаних рядків в головній таблиці.

SET NULL: при видаленні або оновленні пов'язаної рядки з головної таблиці встановлює для стовпця зовнішнього ключа значення NULL. (В цьому випадку стовпець зовнішнього ключа повинен підтримувати установку NULL)

RESTRICT: відхиляє видалення або зміна рядків в головній таблиці при наявності пов'язаних рядків у залежною таблиці.

NO ACTION: те ж саме, що і RESTRICT.

SET DEFAULT: при видаленні пов'язаної рядки з головної таблиці встановлює для стовпця зовнішнього ключа значення за замовчуванням, яке задається за допомогою атрибути DEFAULT. Незважаючи на те, що дана опція в принципі доступна, проте движок InnoDB не підтримує цей вислів.

каскадне видалення

Каскадне видалення дозволяє при видаленні рядка з головної таблиці автоматично видалити всі пов'язані рядки з залежною таблиці. Для цього застосовується опція CASCADE:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id) ON DELETE CASCADE);

Подібним чином працює і вираз ON UPDATE CASCADE. При зміні значення первинного ключа автоматично зміниться значення пов'язаного з ним зовнішнього ключа. Однак оскільки первинні ключі змінюються дуже рідко, та й з принципі не рекомендується використовувати в якості первинних ключів стовпці із змінними значеннями, то на практиці вираз ON UPDATE використовується рідко.

установка NULL

При установки для зовнішнього ключа опції SET NULL необхідно, щоб стовпець зовнішнього ключа допускав значення NULL:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id) ON DELETE SET NULL);

) Ми розбирали, як влаштована реляційна (таблична) база даних і з'ясували, що основними елементами реляційної бази даних є: таблиці, стовпці і рядки, а в математичних поняттях: відносини, атрибути і кортежі. Також часто, рядки називають записами, стовпці називають колонками, а перетин записи і колонки називають осередком.

Важливо згадати, що зміст рядка і назви стовпців повинні бути унікальні в межах однієї бази даних.

Типи даних в базах

Важливо розуміти, що можна створювати бази для будь-яких типів даних: текстів, дат, часу, подій, цифр. Залежно від типу інформації реляційні бази даних ділять на типи. Кожен тип даних (атрибут) має своє позначення:

INTEGER- дані з цілих чисел;
FLOAT - дані з дрібних чисел, так звані дані з плаваючою точкою;
CHAR, VARCHAR - текстові типи даних (символьні);
LOGICAL - логічний тип даних (так / ні);
DATE / TIME - тимчасові дані.

Це основні типи даних, яких насправді набагато більше. Причому, кожна мова програмування має свій набір системних атрибутів (типів даних).

Що таке первинний ключ і зовнішній ключ таблиць реляційних баз даних

Первинний ключ

Вище ми згадували: кожен рядок (запис) БД повинна бути унікальна. Саме первинний ключ у вигляді наборів певних значень, максимально ідентифікують кожен запис. Можна визначити по-іншому. Первинний ключ: набір певних ознак, унікальних для кожного запису. Позначається первинний ключ, як primary key.

Primary key (PK) дуже важливий для кожної таблиці. Поясню чому.

Primary key не дозволяє створювати однакових записів (рядків) в таблиці;
PK забезпечують логічний зв'язок між таблицями однієї бази даних (для реляційних БД).

На логічного зв'язку між таблицями, варто зупинитися докладніше.

ключ зовнішній

Foreign key, коротко FK. Забезпечує однозначну логічний зв'язок, між таблицями одного БД.

Наприклад, є дві таблиці А і В. У таблиці А (взуття), є первинний ключ: розмір, в таблиці В (колір) повинна бути колонка з назвою розмір. У цій таблиці «розмір» це і буде зовнішній ключ для логічного зв'язку таблиць У і А.

Більш складний приклад.

Дві таблиці даних: Люди і Номери телефонів.

Таблиця: Люди

Таблиця: Номери телефонів

У таблиці Номери телефонів PK унікальний. FK цієї таблиці є PK таблиці Люди. Зв'язок між номерами телефонів і людьми забезпечує FK таблиці телефонів. Тобто:

У Зайцева два телефони;
У Волкова два телефони;
У Бєлкіна один телефон.

первинний ключ і зовнішній ключ

На завершення додам, що будь-яка, керуюча базою даних, має технічні можливості скласти первинний ключ.

PRIMARY KEY - первинний ключ, обмеження, що дозволяє однозначно ідентифікувати кожну запис в таблиці SQL.

PRIMARY KEY Oracle
Первинний Ключ ( PRIMARY KEY) Може обмежувати таблиці або їх стовпці. Це обмеження працює так само як і обмеження UNIQUE. Але слід враховувати відмінність між первинними ключами і унікальністю стовпців в способі їх використання з зовнішніми ключами. Первинні ключі не можуть дозволяти значень NULL. Це означає що, подібно полям у обмеженні UNIQUE, будь-яке поле, яке використовується в обмеженні PRIMARY KEY, Має вже бути оголошено NOT NULL.

PRIMARY KEY Oracle. Приклад №1.
Приклад створення таблиці SQL з обмеженням PRIMARY KEY:

Student
(Kod_stud integer NOT NULL PRIMARY KEY,
Fam char (30) NOT NULL UNIQUE,
Adres char (50),
Ball decimal);

Найкраще поміщати обмеження PRIMARY KEY в поле (або в поля), яке буде утворювати унікальний ідентифікатор рядка, і зберегти обмеження UNIQUE для полів які повинні бути унікальними логічно (такі як номери телефону або поле sname), а не для ідентифікації рядків. обмеження PRIMARY KEY може також бути застосована для численних полів, що становлять унікальну комбінацію значень:

PRIMARY KEY Oracle. Приклад №2.

CREATE TABLE Student
(Fam char (30) NOT NULL,
Im char (30) NOT NULL
Adres char (50),
PRIMARY KEY (Fam, Im));

PRIMARY KEY MySQL

PRIMARY KEY SQL / MySQL. Приклад №3.

CREATE TABLE Persons (
P_Id int NOT NULL,
LastName varchar (255) NOT NULL,
FirstName varchar (255),
Address varchar (255),
City varchar (255),
PRIMARY KEY (P_Id));

PRIMARY KEY SQL / MySQL. Приклад №4.

CREATE TABLE `Ad_packages` (
`Id` int (111) NOT NULL auto_increment,
`Title` varchar (132) NOT NULL default»,
`Price` float NOT NULL default '0',
`Type` varchar (22) NOT NULL default»,
`C_type` enum ( 'cash', 'points', 'rur') NOT NULL default 'cash',
PRIMARY KEY ( `Id`)
);

PRIMARY KEY SQL / MySQL. Приклад №5.

CREATE TABLE `gamestat` (
`Id` int (11) NOT NULL auto_increment,
`Game` varchar (10) NOT NULL default 'tuz',
`Stavok` int (11) NOT NULL default '0',
`Usd` float NOT NULL default '0',
`Rur` float NOT NULL default '0',
`Point` float NOT NULL default '0',
`Bank_usd` decimal (12,2) NOT NULL default '0.00',
`Bank_rur` decimal (12,2) NOT NULL default '0.00',
`Bank_point` decimal (12,2) NOT NULL default '0.00',
PRIMARY KEY ( `id`)
);

P rimary Key (Первинний ключ) є полем в таблиці, яке однозначно ідентифікує кожен рядок / запис в таблиці бази даних. Первинні ключі повинні містити унікальні значення. Первинний ключ стовпець не може мати значення.

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

Якщо таблиця має первинний ключ, визначений на будь-якому полі (ях), то ви не можете мати два записи, які мають однакове значення цього поля (їй).

Примітка - Ви могли б використовувати ці поняття при створенні таблиць бази даних.

Створення первинного ключа

Ось синтаксис для визначення атрибута ID в якості первинного ключа в таблиці Customers.

CREATE TABLE CUSTOMERS (ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25), SALARY DECIMAL (18, 2), PRIMARY KEY (ID));

Для того, щоб створити обмеження первинного ключа на стовпці «ID», коли таблиця CUSTOMERS вже існує, використовуйте наступний синтаксис SQL:

ALTER TABLE CUSTOMERS ADD PRIMARY KEY (ID);

Примітка

Якщо ви використовуєте оператор ALTER TABLE, щоб додати первинний ключ, стовпець первинного ключа (їй) повинен був вже оголошений як що не містить NULL значення (якщо таблиця була створена першим).

Для визначення первинного ключа на кілька стовпчиків, використовуйте синтаксис SQL наведений нижче:

CREATE TABLE CUSTOMERS (ID INT NOT NULL, NAME VARCHAR (20) NOT NULL, AGE INT NOT NULL, ADDRESS CHAR (25), SALARY DECIMAL (18, 2), PRIMARY KEY (ID, NAME));

Щоб створити обмеження первинного ключа на колонки «ID» і «NAME», коли таблиця CUSTOMERS вже існує, використовуйте наступний синтаксис SQL.

ALTER TABLE CUSTOMERS ADD CONSTRAINT PK_CUSTID PRIMARY KEY (ID, NAME);

Видалення первинного ключа

Ви можете очистити обмеження первинного ключа з таблиці за допомогою синтаксису, наведеного нижче.

ALTER TABLE CUSTOMERS DROP PRIMARY KEY;