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

Руководство по проектированию реляционных баз данных (7-9 часть из 15) [перевод]

Перевод

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения customer_id в качестве внешнего ключа в таблице заказов.
Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.
(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)
Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.
Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

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

Мы уже достаточно много говорили про ключевые поля, но ни разу их не использовали. Самое интересное, что все работало. Это преимущество, а может недостаток базы данных Microsoft SQL Server и MS Access. В таблицах Paradox такой трюк не пройдет и без наличия ключевого поля таблица будет доступна только для чтения.

В какой-то степени ключи являются ограничениями, и их можно было рассматривать вместе с оператором CHECK, потому что объявление происходит схожим образом и даже используется оператор CONSTRAINT. Давайте посмотрим на этот процесс на примере. Для этого создадим таблицу из двух полей «guid» и «vcName». При этом поле «guid» устанавливается как первичный ключ:

CREATE TABLE Globally_Unique_Data
(
 guid uniqueidentifier DEFAULT NEWID(),
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (Guid)
)

Самое вкусное здесь это строка CONSTRAINT. Как мы знаем, после этого ключевого слова идет название ограничения, и объявления ключа не является исключением. Для именования первичного ключа, я рекомендую использовать именование типа PK_имя, где имя – это имя поля, которое должно стать главным ключом. Сокращение PK происходит от Primary Key (первичный ключ).

После этого, вместо ключевого слова CHECK, которое мы использовали в ограничениях, стоит оператор PRIMARY KEY, Именно это указывает на то, что нам необходима не проверка, а первичный ключ. В скобках указывается одно, или несколько полей, которые будут составлять ключ.

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

В данном примере, в качестве первичного ключа выступает поле типа uniqueidentifier (GUID). Значение по умолчанию для этого поля – результат выполнения серверной процедуры NEWID.

Внимание

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

Для простоты примеров, в качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше, если он будет типа «autoincrement» (автоматически увеличивающееся/уменьшающееся число). В MS SQL Server таким полем является IDENTITY, а в MS Access это поле типа «счетчик».

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

CREATE TABLE Товары
(
  id int IDENTITY(1, 1),
  товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY (id)
)

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

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

CREATE TABLE Товары1
(
  id int IDENTITY(1, 1),
  Товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY 
         (id, )
)

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

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

Естественный и суррогатный ключ

Как определяют первичный ключ таблицы базы данных? Два рассмотренных нами примера – «Студенты» и «Клиенты банка» — иллюстрируют понятия естественного и суррогатного ключа. В таблице клиентов банка мы определили ключ, состоящий из полей «Номер» и «Серия паспорта», использовав уже имеющиеся столбцы. Такой ключ называется естественным, для его определения мы не производили никаких изменений и дополнений. В случае с отношением «Студенты» ни одно поле или сочетание полей не давали нам уникальности. Это вынудило нас ввести дополнительное поле с кодом учащегося. Такой ключ называется суррогатным, для него мы добавили еще один служебный столбец в таблицу. Этот столбец не несет никакой полезной информации и служит только для идентификации записей.

Резюме

• Агрегат — это коллекция данных, с которой мы взаимодействуем как с отдель­ной единицей. Агрегаты образуют границы для операций ACID, применяемых в базе данных.
• Базы данных типа “ключ-значение”, документные базы данных и семейства столбцов представляют собой агрегатно-ориентированные базы данных.
• Агрегаты упрощают управление хранением данных на кластерах.
• Агрегатно-ориентированные базы данных лучше всего работают, когда боль­шинство операций над данными выполняются в одном и том же агрегате; безагрегатные базы данных лучше работают, когда операции выполняются над дан­ными, которые относятся к многочисленным разным формациям.

Вас заинтересует / Intresting for you:

Как правильно выбрать базу дан… 4181 просмотров Administrator Sun, 07 Oct 2018, 08:31:24

Альтернативные модели данных и… 4102 просмотров Дэйзи ак-Макарова Sun, 09 Sep 2018, 10:39:19

Модели данных и языки запросов 551 просмотров Дэн Wed, 06 Mar 2019, 16:11:35

Основные модели данных: иерарх… 5934 просмотров Дэйзи ак-Макарова Sun, 09 Sep 2018, 10:28:33

Author: Денис

Другие статьи автора:

Внешние ключи

• Если сущности А и В связывает сущность С, то она должна содержать внешние ключи, которые соответствуют первичным ключам сущностей А и В.
• Если сущность В характеризует сущность А, то она должна содержать внешний ключ, который соответствует первичному ключу сущности А.

Для каждого из внешних ключей нужно получить ответы на 3 вопроса:

1-й вопрос: может ли значение данного внешнего ключа быть неопределенным (NULL-значением)?

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

2-й вопрос: что должно произойти при УДАЛЕНИИ экземпляра сущности с первичным ключом, на который ссылается внешний ключ?

Например, если удаляется поставщик, осуществивший хотя бы одну поставку, существует 3 варианта, при которых поставка:

• КАСКАДИРУЕТСЯ – удаляются все поставки данного поставщика.
• ОГРАНИЧИВАЕТСЯ – удаляются только не осуществлявшие поставок поставщики. В противном случае удаление отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок данного поставщика значение внешнего ключа устанавливается в NULL (неопределенное), а после данный поставщик удаляется. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

3-й вопрос – какая операция должна выполняться при ОБНОВЛЕНИИ первичного ключа сущности, на который ссылается внешний ключ?

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

• КАСКАДИРУЕТСЯ – обновляется также и внешний ключ в поставках данного поставщика.
• ОГРАНИЧИВАЕТСЯ – обновляются первичные ключи только не осуществлявших поставок поставщиков, в противном случае операция обновления отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок поставщика, который обновляется, внешний ключ устанавливается в NULL-значение, а после выполняется обновление первичного ключа поставщика. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

Следовательно, каждый внешний ключ в проекте должен специфицироваться не только полем или комбинацией полей, которые составляют данный внешний ключ и сущностью, которую идентифицирует этот ключ, но также и ответами на вопросы (3 ограничения, относящиеся к данному внешнему ключу).

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

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

Синтаксис

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

ALTER TABLE table_name DROP PRIMARY KEY;

table_name

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

Пример

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

PgSQL

ALTER TABLE suppliers
DROP PRIMARY KEY;

1 2	ALTERTABLEsuppliers DROPPRIMARYKEY;

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

Пример приведения таблицы ко второй нормальной форме (первичный ключ составной)

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

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

Для хранения таких данных мы создали следующую таблицу.

Таблица проектов организации в первой нормальной форме.

Название проекта	Участник	Должность	Срок проекта (мес.)
Внедрение приложения	Иванов И.И.	Программист	8
Внедрение приложения	Сергеев С.С.	Бухгалтер	8
Внедрение приложения	John Smith	Менеджер	8
Открытие нового магазина	Сергеев С.С.	Бухгалтер	12
Открытие нового магазина	John Smith	Менеджер	12

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

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

Посмотрев на эту таблицу, мы понимаем, что четко идентифицировать каждую строку мы можем только с помощью комбинации столбцов, например, «Название проекта» + «Участник», иными словами, зная «Название проекта» и «Участника», мы можем четко определить конкретную запись в таблице, т.е. каждое сочетание значений этих столбцов является уникальным.

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

Таблица проектов организации. Внедрен составной первичный ключ.

Название проекта	Участник	Должность	Срок проекта (мес.)
Внедрение приложения	Иванов И.И.	Программист	8
Внедрение приложения	Сергеев С.С.	Бухгалтер	8
Внедрение приложения	John Smith	Менеджер	8
Открытие нового магазина	Сергеев С.С.	Бухгалтер	12
Открытие нового магазина	John Smith	Менеджер	12

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

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

Чтобы это проверить, мы можем задать себе несколько вопросов.

Можем ли мы определить «Должность», зная только название проекта? Нет. Для этого нам необходимо знать и участника. Значит, пока все хорошо, по этой части ключа мы не можем четко определить значение неключевого столбца. Идем дальше и проверяем другую часть ключа.

Можем ли мы определить «Должность» зная только участника? Да, можем. Значит наш первичный ключ плохой, и требование второй нормальной формы не выполняется.

Что делать в этом случае?

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

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

Проекты.

Идентификатор проекта	Название проекта	Срок проекта (мес.)
1	Внедрение приложения	8
2	Открытие нового магазина	12

Участники.

Идентификатор участника	Участник	Должность
1	Иванов И.И.	Программист
2	Сергеев С.С.	Бухгалтер
3	John Smith	Менеджер

Связь проектов и участников этих проектов.

Идентификатор проекта	Идентификатор участника
1	1
1	2
1	3
2	2
2	3

Мы создали 3 таблицы:

1. Проекты, в нее мы добавили искусственный первичный ключ
2. Участники, в нее мы также добавили искусственный первичный ключ
3. Связь между проектами и участниками, она нужна для реализации связи «Многие ко многим», так как между этими таблицами связь именно такая

После того как мы привели таблицы базы данных ко второй нормальной форме, мы можем переходить к приведению таблиц до третьей нормальной формы (3NF). Описание, требования и пример приведения таблиц до третьей нормальной формы мы рассмотрим в следующем материале.

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Нравится12Не нравится

Внешний ключ и целостность данных в БД

Все вышеизложенное приводит нас к внешнему ключу (Foreign key) и целостности БД. Foreign key – это поле, ссылающееся на Primary key внешнего отношения. В таблице успеваемости это столбцы «Студент» и «Дисциплина». Их данные отсылают нас к внешним таблицам. То есть поле «Студент» в отношении «Успеваемость» — это Foreign key, а в отношении «Студент» это первичный ключ в базе данных.

Важным принципом построения баз данных является их целостность. И одно из ее правил – целостность по ссылкам. Это значит, что внешний ключ таблицы не может ссылаться на несуществующий Primary key другого отношения. Нельзя удалить из отношения «Студент» запись с кодом 1000 – Иванов Иван, если на нее ссылается запись из таблицы успеваемости. В правильно построенной БД при попытке удаления вы получите ошибку, что это поле используется.

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

Модель данных “ключ-значение” и документная модель

Ранее мы говорили о том, что базы данных типа “ключ—значение” и документные базы данных являются сильно агрегатно-ориентированными. Мы имели в виду, что эти базы данных в основном были сконструированы из агрегатов. Базы данных обоих типов состоят из множества агрегатов, каждый из которых имеет ключ или идентифи­катор, который используется для доступа к данным.

Эти две модели отличаются друг от друга тем, что в базе данных “ключ- значение” агрегат является непроницаемым для базы данных — просто большой черный ящик, состоящий из преимущественно бессмысленных битов. В противопо­ложность этому документная база может видеть структуру агрегата. Преимущество непрозрачности заключается в том, что в агрегате можно хранить все что угодно. База данных может ограничивать общий размер агрегата, но в остальном мы име­ем полную свободу. Документная база данных накладывает ограничения на то, что можно хранить в агрегате, определяя допустимые структуры и типы. Однако за это мы получаем большую гибкость доступа. В хранилище типа “ключ-значение” мы можем просматривать агрегат только с помощью его ключа. В документной базе данных мы можем посылать базе данных запросы, касающиеся полей в агрегате, извлекать части агрегата, а не весь агрегат целиком, причем база данных может соз­давать индексы с учетом содержимого агрегата. На практике разделительная линия между базами данных типа “ключ-значение” и документными базами данных до­вольна расплывчата. Люди часто записывают идентификаторы в документные базы данных, чтобы выполнять поиск в стиле “ключ-значение”. Базы данных, класси­фицированные как базы типа “ключ-значение”, могут предлагать новые структуры для данных, помимо непрозрачных агрегатов. Например, база данных Riak позво­ляет добавлять метаданные к агрегатам для индексирования и установления связей между агрегатами, a Redis позволяет разбивать агрегаты на списки или множества. Кроме того, можно обеспечить механизм запросов с помощью интегрированных средств поиска, как в базе данных Solr. Например, поисковый механизм базы данных Riak, аналогичный поисковому механизму базы Solr, выполняет поиск агрегатов, хранящихся в виде структур JSON или XML.

Несмотря на такое нечеткое разделение, эти две категории в целом отличаются друг от друга. Базы данных типа “ключ—значение”, как правило, выполняют поиск агрегатов по ключу. В документных базах данных пользователь должен подать запрос, основан­ный на внутренней структуре документа; это может быть ключ, но, скорее всего, это будет нечто другое.

Перед началомBefore You Begin

ОграниченияLimitations and Restrictions

• В таблице возможно наличие только одного ограничения по первичному ключу.A table can contain only one PRIMARY KEY constraint.

• Все столбцы с ограничением PRIMARY KEY должны иметь признак NOT NULL.All columns defined within a PRIMARY KEY constraint must be defined as NOT NULL. Если допустимость значения NULL не указана, то для всех столбцов c ограничением PRIMARY KEY устанавливается признак NOT NULL.If nullability is not specified, all columns participating in a PRIMARY KEY constraint have their nullability set to NOT NULL.

PermissionsPermissions

Создание новой таблицы с первичным ключом требует разрешения CREATE TABLE в базе данных и разрешения ALTER на схему, в которой создается таблица.Creating a new table with a primary key requires CREATE TABLE permission in the database and ALTER permission on the schema in which the table is being created.

Создание первичного ключа в существующей таблице требует разрешения ALTER на таблицу.Creating a primary key in an existing table requires ALTER permission on the table.

Связывание таблиц

Если для какой-то из таблиц не было определено ключевое поле, то в поле Тип отношения отображается текст «Не определено».

1. Откройте окно Схема данных, нажав кнопку на панели инструментов
2. В диалоговом окне Добавление таблицы выберите вкладку Таблицы и, нажимая кнопку Добавить, разместите в окне Схема данных все ранее созданные таблицы базы данных, список которых будет отображен в диалоговом окне. Можно добавить все таблицы сразу, выделив 1-ую таблицу и нажав Shift — последнюю таблицу.
3. Нажмите кнопку Закрыть. В результате в окне Схема данных будут представлены все таблицы базы данных КОЛЛЕДЖ со списками своих полей.
4. Установите связь между таблицами ГРУППА и СТУДЕНТ по простому ключу Номер Группы или Код группы (смотри в своей БД). Для этого в окне Схема данных установите курсор мыши на ключевое поле НГ главной таблицы ГРУППА и перетащите это поле на поле Номер Группы в подчиненной таблице СТУДЕНТ  Для удаления ошибочной связи в окне Схема данных выделите ненужную связь и нажмите Del.
5. В открывшемся окне Изменение связей в строке Тип отношения установится один-ко-многим. Отметьте доступный для этого типа отношений параметр Обеспечение целостности данных.
6. Установите флажки каскадное обновление и удаление связанных полей, тогда будет обеспечена автоматическая корректировка данных для сохранения целостности во взаимосвязанных таблицах. Нажмите Создать. Чтобы линии связи не пересекались и были удобны для восприятия, расположите таблицы в окне Схемы данных в соответствии с их относительной подчиненностью.
7. Установите связи по простому ключу для других пар таблиц:

ПРЕДМЕТ—ПРЕПОДАВАТЕЛЬ 

ПРЕДМЕТ-ЗАНЯТИЯ 

ПРЕПОДАВАТЕЛЬ—ГРУППА

ГРУППА—ЭКЗАМЕН 

При помощи Microsoft Equation 3.0

Стоит сразу сказать, что данный способ для вставки знака корня в документ отлично подходит как для соответствия всем нормам, так и для применения его во всех версиях программы. А пользоваться мы будем инструментом под названием Microsoft Equation 3.0.

Для начала необходимо открыть интерфейс самой утилиты, для этого:

1. Перейдите во вкладку “Вставка”.
2. В группе инструментов “Текст” нажмите по кнопке “Объекты”.
3. В появившемся окне выберите “Microsoft Equation 3.0”, который находится в списке “Тип объекта”.
4. Нажмите кнопку “ОК”.

После этого в месте где был установлен курсор, появится форма для заполнения

Обратите внимание также на то, что внешний вид “Ворда” довольно сильно поменяется

Для вставки знака корня вам необходимо в окне инструментов “Формула” нажать на кнопку “Шаблоны дробей и радикалов”. Ее расположение вы можете наблюдать на изображении ниже.

Теперь в выпадающем списке нужно выбрать соответствующий шаблон. После этого в поле для набора формул появится знак корня, а рядом с ним пустая ячейка, в которую можно вводить число. После того как число было введено, переключится на стандартный интерфейс программы можно, нажав левую кнопку мыши (ЛКМ) за пределами формы для ввода формул.

Назовите четыре основных типа соединения в SQL

Чтобы объединить две таблицы в одну, следует использовать оператор . Соединение таблиц может быть внутренним () или внешним (), причём внешнее соединение может быть левым (), правым () или полным ().

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

Рассмотрим пример соединения SQL таблиц с использованием . Следующий запрос выбирает все заказы с информацией о клиенте:

9

Вставка рисунка или объекта

Создание других таблиц для этой базы данных — аналогичное. 

Создайте еще 5 таблиц самостоятельно.

Вставка в запись рисунка или объекта

Рисунок или объект добавляется из имеющегося файла либо создается в приложении OLE (например, в MS Paint), а затем вставляется в текущую запись.

Рассмотрим размещение объекта OLE на примере поля Фотография начальника в таблице Преподаватели. Фотографии хранятся в формате графического редактора Paint в файлах с расширением .bmp. Если рисунка в вашем файле нет, то создайте его самостоятельно и сохраните.

1. В окне базы данных установите курсор на таблице Преподаватели и нажмите кнопку Открыть
2. Заполните строки (записи) открывшейся таблицы данными в соответствии с названиями столбцов (полей)
3. Для размещения поля Фотография начальника выполните внедрение объекта OLE в файл базы данных. Установите курсор в соответствующее поле таблицы. Выполните команду меню Вставка|Объект
4. В окне Вставка объекта выберите тип объекта Paintbrush Picture и установите флажок Создать из файла
5. В этом окне можно ввести имя файла, содержащего фотографию.
6. Для просмотра внедренного объекта установите курсор в соответствующее поле и дважды щелкните кнопкой мыши
7. Чтобы вернуться из программы Paint, выполните команду Файл|Выход и возврат к таблице Преподаватели.

Размещение данных типа МЕМО в таблице

В таблице ПРЕДМЕТ предусмотрено поле ПРОГРАММА, которое будет содержать длинный текст – краткую программу курса. Для такого поля выберите тип данных ПолеМЕМО.

Выводы

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