Первичный ключ и внешний ключ таблиц реляционных баз данных

Что такое внешний ключ

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

Рисунок 1: Первичный и Внешний ключ

Например, предположим, что есть база данных продаж. Имеются таблицы клиентов и продуктов. Таблица customer содержит столбцы customer_id, name, address и contact_no. Первичный ключ таблицы клиента — customer_id. Товар имеет столбцы product_id, name, quality. Первичный ключ таблицы продукта — product_id. Размещение product_id в таблице клиентов создаст связь между двумя таблицами. Product_id в таблице product является первичным ключом, но это внешний ключ в customer_table. Аналогично, можно соединять таблицы в базе данных, используя внешний ключ.

Создать первичный ключ (оператор ALTER TABLE)

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

Синтаксис

Синтаксис для создания первичного ключа с помощью оператора ALTER TABLE в SQL.

ALTER TABLE table_name
ADD CONSTRAINT constraint_name
PRIMARY KEY (column1, column2, … column_n);

table_name

Имя таблицы для изменения. Это таблица, к которой вы хотите добавить первичный ключ

constraint_name

Название первичного ключа

column1, column2, … column_n

Столбцы, составляющие первичный ключ

Пример

Давайте посмотрим, как создать первичный ключ с помощью оператора ALTER TABLE в SQL. Скажем так, у нас уже есть таблица suppliers, созданная в нашей базе данных. Мы могли бы добавить первичный ключ к таблице suppliers с помощью следующего оператора ALTER TABLE.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id);

В этом примере мы создали первичный ключ для существующей таблицы suppliers, который называется sources_pk. Он состоит из столбца supplier_id.
Мы также могли бы создать первичный ключ с более чем одним полем, как показано ниже.

PgSQL

ALTER TABLE suppliers
ADD CONSTRAINT suppliers_pk
PRIMARY KEY (supplier_id, supplier_name);

Этот пример создал бы первичный ключ с именем supplier_pk, который состоит из комбинации столбцов supplier_id и supplier_name.

Составной ключ (composite key)

Что касается составного ключа — это несколько первичных ключей в таблице. Таким образом, создав composite key, уникальность записи будет проверяться по полям, которые объединенные в этот ключ.

Бывают ситуации, когда при вставке в таблицу нужно проверять запись на уникальность сразу по нескольким полям. Вот для этого и придуман составной ключ. Для примера я создам простую таблицу с composite key, чтобы показать синтаксис:

create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

В примере выше два поля объединенные в составной ключ и в таблице не будет записей с этими одинаковыми полями.

Это все, что касается ключей в SQL. Это небольшое пособие — подготовка к статье связи sql где мы подробно рассмотрим как объединять таблицы, чтобы они составляли единую базу данных.

Тестирование

этой ссылке

• Всего три серии тестов с длиной текстового поля в записи 80, 800 и 8000 байт соответственно (количество символов в тестовой программе будет в два раза меньше в каждом из случаев, так как один символ в NVARCHAR занимает два байта).
• В каждой из серий — по 5 запусков, каждый из которых добавляет по 10000 записей в каждую из таблиц. По результатам каждого из запусков можно будет проследить зависимость времени вставки от количества строк, уже находящихся в таблице.
• Перед началом каждой из серий таблицы полностью очищаются.

• Использование генерации GUID на стороне базы данных в разы медленнее, чем генерации на стороне клиента. Это связано с затратами на чтение только что добавленного идентификатора. Детали этой проблемы рассмотрены в конце статьи.
• Вставка записей с автоинкрементным ключом даже немного медленнее, чем с GUID-ом, присвоенным на клиенте.
• Разницы между последовательным и непоследовательным GUID практически не видно на небольших записях. На больших записях разница появляется с ростом количества строк в таблице, но она не выглядит существенной.

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

Столбец, который в базе данных должен быть уникальным помечают первичным ключом. Первичный ключ или primary key означает, что в таблице значение колонки primary key не может повторяться. Таким образом данный ключ позволяет однозначно идентифицировать запись в таблице не боясь при этом, что значение столбца повториться. Сразу пример: допустим у Вас есть таблица пользователей. В данной таблице есть поля: ФИО, год рождения, телефон. Как идентифицировать пользователя? Таким параметрам как ФИО и телефон доверять нельзя. Ведь у нас может быть несколько пользователей не только с одинаковой фамилией, но и с именем. Телефон может меняться со временем и пользователь с номером телефона может оказаться не тем кто у нас в базе данных.

Вот для этого и придумали первичный ключ. Один раз присвоили уникальный идентификатор и все. В mySql на примере которой мы выполняем все примеры из цикла статей по SQL поле AUTO_INCREMENT нельзя задать если не указать, что это первичный ключ.

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

Думаю, что не стоит упоминать, что поле помеченное как первичный ключ не может быть пустым при создании записи.

Разница между первичным ключом и внешним ключом

Определение

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

Количество связанных таблиц

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

Повторяющиеся значения

Кроме того, еще одно различие между первичным ключом и внешним ключом состоит в том, что значения первичного ключа не могут иметь повторяющиеся значения, тогда как значения внешнего ключа могут иметь повторяющиеся значения.

Количество ключей

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

использование

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

Заключение

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

Ключ-значение

В этих БД запросы только на основе ключа — вы запрашиваете ключ и получаете его значение.

Такие БД не поддерживают запросы между различными значениями записей, вроде такого: выбрать все записи, где город — Нью-Йорк.Полезное свойство этих БД — поле времени жизни (Time-to-Live, TTL), в котором можно задать отдельно для каждой записи и состояния, когда их нужно удалить из БД.

Достоинства

Это очень быстрые БД. Во-первых, потому что используют уникальные ключи, во-вторых, потому что большинство БД типа ключ-значение хранят данные в оперативной памяти, что обеспечивает быстрый доступ к данным.

Недостатки

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

Использование

В основном используются для кэширования, потому что быстрые и не требуют сложных запросов. Поле времени жизни для кэширования также очень полезно. Такие БД могут использоваться для любых данных, которые требуют быстрых запросов и соответствуют формату ключ-значение. Примеры таких баз:

• Redis
• Memcached

Отношение один к одному

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

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

 
CREATE TABLE Names
(
 idName uniqueidentifier DEFAULT NEWID(), 
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (idName)
)

CREATE TABLE Phones
(
 idPhone uniqueidentifier DEFAULT NEWID(),
 vcPhone varchar(10), 
 CONSTRAINT PK_idPhone PRIMARY KEY (idPhone),
 CONSTRAINT FK_idPhone FOREIGN KEY (idPhone)
   REFERENCES Names (idName)
)

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

Представление в базе данных

Рассмотрим пример таблицы в базе данных с обоими видами ключей:

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

      IF
      NOT
      EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'.') AND type in (N'U'))
BEGINCREATETABLE .(
    IDENTITY(1,1) NOTNULL,
   (50) NOTNULL,
   (50) NOTNULL,
   (400) NOTNULL,
 CONSTRAINT  PRIMARYKEYCLUSTERED 
(
   ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON 
) ON 
END

В данном примере у нас суррогатный ключ Id является первичным ключом, а поля Title и Url входят в дополнительный ключ. Уникальность обеспечивается следующим ограничением (constraint):

      IF
      NOT
      EXISTS (
  SELECT * 
  FROM sys.indexes 
  WHERE object_id = OBJECT_ID(N'.')
AND name = N'IX_NK_TitleUrl'
)
  CREATEUNIQUENONCLUSTEREDINDEX  ON . 
  (
     ASC,
     ASC
  )  WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
           SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, 
           DROP_EXISTING = OFF, ONLINE = OFF, 
           ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON)
    ON  

Примеры ключей-кандидатов

Некоторые типы данных легко поддаются давлению:

• Международные стандартные номера книг — ISBN уникально идентифицируют книги и связанные с ними средства массовой информации. Выпуск ISBN жестко регулируется отраслевыми привратниками, а ISBN, как правило, никогда не используются издателями.
• Номера банковских счетов. Большинство банков не перерабатывают номера счетов.
• Серийные номера. Хотя серийные номера не регулируются в разных отраслях промышленности, в контексте одного поставщика серийный номер всегда должен быть уникальным.
• Номера водительских лицензий. Обычно эти номера не дублируются. Однако человек, который переезжает из штата в штат, может иметь более одного номера DL.
• Национальные провайдеры-провайдеры и другие лицензированные медицинские работники имеют по крайней мере один НКО, уникальный для них, выпущенный Департаментом здравоохранения и социальных служб США.

Однако некоторые типы информации, которые могут показаться хорошими кандидатами, фактически оказываются проблематичными:

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

SQL Учебник

SQL ГлавнаяSQL ВведениеSQL СинтаксисSQL SELECTSQL SELECT DISTINCTSQL WHERESQL AND, OR, NOTSQL ORDER BYSQL INSERT INTOSQL Значение NullSQL Инструкция UPDATESQL Инструкция DELETESQL SELECT TOPSQL MIN() и MAX()SQL COUNT(), AVG() и …SQL Оператор LIKESQL ПодстановочныйSQL Оператор INSQL Оператор BETWEENSQL ПсевдонимыSQL JOINSQL JOIN ВнутриSQL JOIN СлеваSQL JOIN СправаSQL JOIN ПолноеSQL JOIN СамSQL Оператор UNIONSQL GROUP BYSQL HAVINGSQL Оператор ExistsSQL Операторы Any, AllSQL SELECT INTOSQL INSERT INTO SELECTSQL Инструкция CASESQL Функции NULLSQL ХранимаяSQL Комментарии

Создание файла базы данных

При запуске Access открывается диалоговое окно — Окно запуска, в котором предлагается создать новую БД, запустить Мастера БД или открыть существую­щую БД.

В Access поддерживаются два способа создания БД. Можно создать пустой файл БД, а затем разрабатывать таблицы, формы, отчеты и другие объекты, добав­ляя их в БД. Такой способ является профессиональным и наиболее гибким, но тре­бует отдельного определения каждого элемента БД. При выборе такого способа создания БД надо в окне запуска установить флажок Новая база данных. В рас­крывшемся окне Файл новой базы данных следует выбрать каталог и задать имя создаваемой БД. Раскроется Окно базы данных.

Вниманию студентов! Студенческие БД должны создаваться в директории StudentGRNNN.

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

Флажок Открыть базу данных окна запуска позволяет открыть ранее

созданную БД, выбрав ее имя из предлагаемого списка. При выборе Другие файлы предоставляется каталог, из которого можно открыть нужную БД.

• АлтГТУ 419
• АлтГУ 113
• АмПГУ 296
• АГТУ 266
• БИТТУ 794
• БГТУ «Военмех» 1191
• БГМУ 172
• БГТУ 602
• БГУ 153
• БГУИР 391
• БелГУТ 4908
• БГЭУ 962
• БНТУ 1070
• БТЭУ ПК 689
• БрГУ 179
• ВНТУ 119
• ВГУЭС 426
• ВлГУ 645
• ВМедА 611
• ВолгГТУ 235
• ВНУ им. Даля 166
• ВЗФЭИ 245
• ВятГСХА 101
• ВятГГУ 139
• ВятГУ 559
• ГГДСК 171
• ГомГМК 501
• ГГМУ 1967
• ГГТУ им. Сухого 4467
• ГГУ им. Скорины 1590
• ГМА им. Макарова 300
• ДГПУ 159
• ДальГАУ 279
• ДВГГУ 134
• ДВГМУ 409
• ДВГТУ 936
• ДВГУПС 305
• ДВФУ 949
• ДонГТУ 497
• ДИТМ МНТУ 109
• ИвГМА 488
• ИГХТУ 130
• ИжГТУ 143
• КемГППК 171
• КемГУ 507
• КГМТУ 269
• КировАТ 147
• КГКСЭП 407
• КГТА им. Дегтярева 174
• КнАГТУ 2909
• КрасГАУ 370
• КрасГМУ 630
• КГПУ им. Астафьева 133
• КГТУ (СФУ) 567
• КГТЭИ (СФУ) 112
• КПК №2 177
• КубГТУ 139
• КубГУ 107
• КузГПА 182
• КузГТУ 789
• МГТУ им. Носова 367
• МГЭУ им. Сахарова 232
• МГЭК 249
• МГПУ 165
• МАИ 144
• МАДИ 151
• МГИУ 1179
• МГОУ 121
• МГСУ 330
• МГУ 273
• МГУКИ 101
• МГУПИ 225
• МГУПС (МИИТ) 636
• МГУТУ 122
• МТУСИ 179
• ХАИ 656
• ТПУ 454
• НИУ МЭИ 641
• НМСУ «Горный» 1701
• ХПИ 1534
• НТУУ «КПИ» 212
• НУК им. Макарова 542
• НВ 777
• НГАВТ 362
• НГАУ 411
• НГАСУ 817
• НГМУ 665
• НГПУ 214
• НГТУ 4610
• НГУ 1992
• НГУЭУ 499
• НИИ 201
• ОмГТУ 301
• ОмГУПС 230
• СПбПК №4 115
• ПГУПС 2489
• ПГПУ им. Короленко 296
• ПНТУ им. Кондратюка 119
• РАНХиГС 186
• РОАТ МИИТ 608
• РТА 243
• РГГМУ 118
• РГПУ им. Герцена 124
• РГППУ 142
• РГСУ 162
• «МАТИ» — РГТУ 121
• РГУНиГ 260
• РЭУ им. Плеханова 122
• РГАТУ им. Соловьёва 219
• РязГМУ 125
• РГРТУ 666
• СамГТУ 130
• СПбГАСУ 318
• ИНЖЭКОН 328
• СПбГИПСР 136
• СПбГЛТУ им. Кирова 227
• СПбГМТУ 143
• СПбГПМУ 147
• СПбГПУ 1598
• СПбГТИ (ТУ) 292
• СПбГТУРП 235
• СПбГУ 582
• ГУАП 524
• СПбГУНиПТ 291
• СПбГУПТД 438
• СПбГУСЭ 226
• СПбГУТ 193
• СПГУТД 151
• СПбГУЭФ 145
• СПбГЭТУ «ЛЭТИ» 380
• ПИМаш 247
• НИУ ИТМО 531
• СГТУ им. Гагарина 114
• СахГУ 278
• СЗТУ 484
• СибАГС 249
• СибГАУ 462
• СибГИУ 1655
• СибГТУ 946
• СГУПС 1513
• СибГУТИ 2083
• СибУПК 377
• СФУ 2423
• СНАУ 567
• СумГУ 768
• ТРТУ 149
• ТОГУ 551
• ТГЭУ 325
• ТГУ (Томск) 276
• ТГПУ 181
• ТулГУ 553
• УкрГАЖТ 234
• УлГТУ 536
• УИПКПРО 123
• УрГПУ 195
• УГТУ-УПИ 758
• УГНТУ 570
• УГТУ 134
• ХГАЭП 138
• ХГАФК 110
• ХНАГХ 407
• ХНУВД 512
• ХНУ им. Каразина 305
• ХНУРЭ 324
• ХНЭУ 495
• ЦПУ 157
• ЧитГУ 220
• ЮУрГУ 306

Полный список ВУЗов

Чтобы распечатать файл, скачайте его (в формате Word).

SQL PRIMARY KEY в ALTER TABLE

Чтобы создать ограничение первичного ключа для столбца «ID», когда таблица уже создана, используйте следующий SQL:

MySQL / SQL Server / Oracle / MS Access:

ALTER TABLE Persons
ADD PRIMARY KEY (ID);

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

MySQL / SQL Server / Oracle / MS Access:

ALTER TABLE Persons
ADD CONSTRAINT PK_Person PRIMARY KEY (ID,LastName);

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

Ключи и ссылочная целостность в MySQL и Oracle

Oracle поддерживает первичные, уникальные, внешние ключи в полном объеме. Oracle поддерживает следующие правила ссылочной целостности:

• NO ACTION (устанавливается по умолчанию) в более жестком, чем по стандарту SQL 92, варианте: запрещается изменение и удаление строк родительской таблицы, для которых имеются связанные строки в дочерних таблицах.
• ON DELETE CASCADE.

Более сложные правила ссылочной целостности в Oracle можно реализовать через механизм триггеров.

MySQL версии 4.1 (последняя на момент написания статьи стабильная версия) позволяет в командах CREATE / ALTER TABLE задавать фразы REFERENCES / FOREIGN KEY, но в работе никак их не учитывает и реально внешние ключи не создает. Соответственно правила ссылочной целостности, реализуемые через внешние ключи, в MySQL не поддерживаются. И все заботы по обеспечению целостности и непротиворечивости информации в базе MySQL ложатся на плечи разработчиков клиентских приложений.

Ключи

Последнее обновление: 02.07.2017

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

Суперключ

Superkey (суперключ) — комбинация атрибутов (столбцов), которые уникально идентифицируют каждую строку таблицы. Это могут быть и все столбцы, и
несколько и и один. При этом строки, которые содержат значения этих атрибутов, не должны повторяться.

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

• FirstName (имя)

• LastName (фамилия)

• Year (год рождения)

• Phone (номер телефона)

Какие атрибуты в данном случае могут составлять суперключ:

• {FirstName, LastName, Year, Phone}

• {FirstName, Year, Phone}

• {LastName, Year, Phone}

• {FirstName, Phone}

• {LastName, Phone}

• {Year, Phone}

• {Phone}

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

А вот, к примеру, набор не является суперключом, так как у нас теоретически могут быть как минимум
два студента с одинаковыми именем, фамилией и годом рождения.

Потенциальный ключ

Candidate key (потенциальный ключ) — представляет собой минимальный суперключ отношения (таблицы), то есть набор атрибутов, который удовлетворяет ряду условий:

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

• Уникальность: он должен иметь уникальные значения вне зависимости от изменения строки

• Наличие значения: он не должен иметь значения NULL, то есть он обязательно должен иметь значение.

Возьмем ранее выделенные суперключи и найдем среди них candidate key. Первый пять суперключей не соответствуют первому условию, так как все их можно сократить до суперключа {Phone}:

• {FirstName, LastName, Year, Phone}

• {FirstName, Year, Phone}

• {LastName, Year, Phone}

• {FirstName, Phone}

• {LastName, Phone}

• {Year, Phone}

Суперключ {Phone} соответствует первому и второму условию, так как он имеет уникальное значение (в данном случае все пользователи могут иметь только уникальные телефонные номера). Но соответствует ли он третьему условию?
В целом нет, так как теоретически студент может и не иметь телефона. В этом случае атрибут Phone будет иметь значение NULL, то есть значение
будет отсутствовать.

В то же время это может зависеть от ситуации. Если в какой-то систему номер телефона является неотъемлемым атрибутом, например, используется для регистрации и входа в систему, то его можно считать потенциальным ключом. Но
в данном случае мы рассматриваем общую ситуацию. И для понимания потенциального ключа необходимо отталкиваться от конкретной системы, которую описывает база данных.

И в таком случае суперключи таблицы не содержат потенциального ключа.

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

Первичный ключ (primary key) непосредственно применяется для идентификации строк в таблице. Он должен соответствовать следующим ограничениям:

• Первичный ключ должен быть уникальным все время

• Он должен постоянно присутствовать в таблице и иметь значение

• Он не должен часто менять свое значение. В идеале он вообще не должен изменять значение.

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

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

Если же потенциальные ключи отсутствуют, то для первичного ключа можно добавить к сущности специальный атрибут, который, как правило, называется, Id или
имеет форму Id (например, StudentId), либо может иметь другое название. И обычно данный атрибут принимает целочисленное значение, начиная с 1.

Если же у нас есть несколько потенциальных ключей, то те потенциальные ключи, которые не составляют первичный ключ, являются альтернативными ключами
(alternative key).

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

• Name (имя пользователя)

• Password (пароль)

• Phone (телефонный номер)

НазадВперед

Пределы и ограничения

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

• Если столбцу, имеющему ограничение внешнего ключа, задается значение, отличное от NULL, такое же значение должно существовать и в указываемом столбце. В противном случае будет возвращено сообщение о нарушении внешнего ключа. Для обеспечения проверки всех значений сложного ограничения внешнего ключа задайте параметр NOT NULL для всех столбцов, участвующих в индексе.

• Ограничения FOREIGN KEY могут ссылаться только на таблицы в пределах той же базы данных на том же сервере. Межбазовую ссылочную целостность необходимо реализовать посредством триггеров. Дополнительные сведения см. в статье об инструкции CREATE TRIGGER.

• Ограничения FOREIGN KEY могут ссылаться на другие столбцы той же таблицы и считаются ссылками на себя.

• Ограничение FOREIGN KEY, определенное на уровне столбцов, может содержать только один ссылочный столбец. Этот столбец должен принадлежать к тому же типу данных, что и столбец, для которого определяется ограничение.

• Ограничение FOREIGN KEY, определенное на уровне таблицы, должно содержать такое же число ссылочных столбцов, какое содержится в списке столбцов в ограничении. Тип данных каждого ссылочного столбца должен также совпадать с типом соответствующего столбца в списке столбцов.

• Компонент Database Engine не имеет предопределенного ограничения на число ограничений FOREIGN KEY, которые могут содержаться в таблице, ссылающейся на другие таблицы. Компонент Database Engine также не ограничивает число ограничений FOREIGN KEY, принадлежащих другим таблицам, которые ссылаются на определенную таблицу. Но фактическое количество используемых ограничений FOREIGN KEY ограничивается конфигурацией оборудования, базы данных и приложения. Максимальное количество таблиц и столбцов, на которые может ссылаться таблица в качестве внешних ключей (исходящих ссылок), равно 253. SQL Server 2016 (13.x); и последующие версии увеличивает ограничение на количество других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящие ссылки), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Увеличение имеет следующие ограничения:

  • Превышение 253 ссылок на внешние ключи поддерживается только для операций DELETE и UPDATE DML. Операции MERGE не поддерживаются.
  • Таблица со ссылкой внешнего ключа на саму себя по-прежнему ограничена 253 ссылками на внешние ключи.
  • Превышение числа в 253 ссылки на внешние ключи в настоящее время недоступно для индексов columnstore, оптимизированных для памяти таблиц или Stretch Database.

• Ограничения FOREIGN KEY не применяются к временным таблицам.

• Если внешний ключ определен на столбце определяемого пользователем типа данных CLR, реализация этого типа должна поддерживать двоичную сортировку. Дополнительные сведения об определяемых пользователем типах данных CLR см. в разделе Определяемые пользователем типы данных CLR.

• Столбец типа varchar(max) может участвовать в ограничении FOREIGN KEY только при условии, что первичный ключ, на который он ссылается, также имеет тип данных varchar(max) .

Удалить первичный ключ

В SQL вы можете удалить первичный ключ, используя оператор ALTER TABLE.

Синтаксис

Синтаксис для удаления первичного ключа в SQL.

ALTER TABLE table_name
DROP PRIMARY KEY;

table_name

Имя таблицы для изменения. Это таблица, первичный ключ которой вы хотите удалить

Пример

Давайте посмотрим, как удалять первичный ключ с помощью оператора ALTER TABLE в SQL.

PgSQL

ALTER TABLE suppliers
DROP PRIMARY KEY;

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

Достоинства документных баз

• Позволяют хранить объекты с разной структурой.
• Могут отображать почти все структуры данных, включая объекты на основе ООП, списки и словари, используя старый добрый JSON.
• Несмотря на то, что NoSQL не схематичны по своей природе, они часто поддерживают проверку схемы. Это значит, что вы можете сделать коллекцию со схемой. Эта схема не будет простой, как таблица: это будет JSON схема со специфическими полями.
• Запросы к NoSQL очень быстрые — каждая запись независима и, следовательно, время запроса не зависит от размера базы. По той же причине эта БД поддерживает параллельность.
• В NoSQL масштабирование БД осуществляется добавлением компьютеров и распределением данных между ними, этот метод называется горизонтальное масштабирование. Оно позволяет автоматически добавлять ресурсы к БД, когда нам нужно, не провоцируя простои.

Выводы

• Если по каким-либо критериям, указанным в начале статьи, возникла надобность использовать GUID в качестве первичного ключа — наилучшим вариантом в плане производительности будет последовательный GUID, сгенерированный для каждой записи на клиенте.
• Если создание GUID на клиенте по каким-либо причинам неприемлемо — можно воспользоваться генерацией идентификатора на стороне базы через NEWSEQUENTIALID(). Entity Framework делает это по умолчанию для GUID ключей, генерируемых на стороне базы. Но следует учесть, что производительность вставки будет заметно меньше по сравнению с созданием идентификатора на стороне клиента. Для проектов, где количество вставок в таблицы невелико, эта разница не будет критична. Еще, скорее всего, этот оверхед можно избежать в сценариях, где не нужно сразу же получать идентификатор вставленной записи, но такое решение не будет универсальным.
• Если в вашем проекте уже используются непоследовательные GUID, то следует задуматься об исправлении, если количество вставок в таблицы велико и размер базы значительно больше, чем размер доступной оперативной памяти.
• У других СУБД разница в производительности может быть совершенно другой, поэтому полученные результаты можно рассматривать только применительно к Microsoft SQL Server. В то время как базовые критерии, указанные в начале статьи, справедливы независимо от конкретной СУБД.