Sql первичный ключ

Введение

Создание современных бизнес-приложений редко обходится без помощи систем объектно-реляционного отображения (ORM). Хотя в целом такие системы существенно упрощают работу прикладного программиста, но некоторые задачи они все же не автоматизируют. Так, многие ORM перекладывают на программиста задачу реализации методов сравнения объектов (проверки их эквивалентности). Учитывая, что количество классов-сущностей, получаемых в процессе отображения, может быть довольно большим, это порождает большой объем монотонной и однообразной работы, что чревато появлением ошибок.

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

В данной работе предлагается механизм автоматической генерации методов проверки эквивалентности объектов (Equals() и GetHashCode()) на основе естественных ключей, имеющихся в БД, и приводится пример реализации этого механизма для ORM-системы BLToolkit.

SQL FOREIGN KEY в CREATE TABLE

Следующий SQL создает внешний ключ в столбце «PersonID» при создании таблицы «Orders»:

MySQL:

CREATE TABLE Orders
(
   
OrderID int NOT NULL,
   
OrderNumber int NOT NULL,
   
PersonID int,
   
PRIMARY KEY (OrderID),
   
FOREIGN KEY (PersonID) REFERENCES Persons(PersonID)
);

SQL Server / Oracle / MS Access:

CREATE TABLE Orders
(
   
OrderID int NOT NULL PRIMARY KEY,
   
OrderNumber int NOT NULL,
   
PersonID int FOREIGN KEY REFERENCES Persons(PersonID)
);

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

MySQL / SQL Server / Oracle / MS Access:

CREATE TABLE Orders
(
   
OrderID int NOT NULL,
   
OrderNumber int NOT NULL,
   
PersonID int,
   
PRIMARY KEY (OrderID),
   
CONSTRAINT FK_PersonOrder FOREIGN KEY (PersonID)
   
REFERENCES Persons(PersonID)
);

SQL CREATE TABLE с PRIMARY KEY CONSTRAINT для большего количества столбцов

В следующем разделе мы обсудим использование SQL PRIMARY KEY CONSTRAINT вместе с оператором CREATE TABLE для двух или более столбцов.

Пример:

В следующем примере создается таблица. Таблица должна содержать ПЕРВИЧНЫЙ КЛЮЧ с комбинацией двух столбцов ‘cust_code’ и ‘cust_city’. Вот имя поля и типы данных:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ	скованность
cust_code	голец	6		нет	ОСНОВНОЙ КЛЮЧ
CUST_NAME	голец	25		нет
cust_city	голец	25		нет	ОСНОВНОЙ КЛЮЧ
класс	целое число			да
agent_code	голец	6		нет

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

Выход:

Определение первичных ключей в SQL

Первичные ключи определены в посредством ограничения PRIMARY KEY. Синтаксис для добавления такого ограничения к существующей таблице определен в SQL: 2003 следующим образом:

ALTER TABLE <table identifier> 
    ADD  CONSTRAINT <constraint identifier>  
    PRIMARY KEY ( <column name>  {, <column name> }...  )

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

Обратите внимание, что некоторые СУБД требуют явной пометки столбцов первичного ключа как .

CREATE TABLE table_name (
   
   ...
)

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

CREATE TABLE table_name (
   id_col  INT  PRIMARY KEY,
   col2    CHARACTER VARYING(20),
   ...
)

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

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

Пример:

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

Так что не стоит создавать PRIMARY KEY для ‘agent_name’. ‘Agent_code’ может быть единственным и исключительным выбором для PRIMARY KEY для этой таблицы.

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ	скованность
agent_code	голец	6		нет	ОСНОВНОЙ КЛЮЧ
имя агента	голец	40		нет
рабочая область	голец	35		да
комиссия	десятичный	10	2	да
номер телефона	голец	17		да

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

Ограничение первичного ключа на уровне столбца:

Код SQL:

Ограничение первичного ключа на уровне таблицы:

Код SQL:

Теория

Первичный ключ таблицы БД может быть естественным или суррогатным.

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

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

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

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

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

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

На основании дополнительных ключей можно автоматически генерировать код проверки объектов на эквивалентность.

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

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

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

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

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

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

В 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. Нам не нужно указывать имя первичного ключа, поскольку в таблице может быть только один первичный ключ.

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

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

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

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

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

• Первичный ключ не может включать больше 16 столбцов, а общая длина ключа не может превышать 900 байт.

• Индекс, формируемый ограничением первичного ключа, не может повлечь за собой выход количества индексов в таблице за пределы в 999 некластеризованных индексов и 1 кластеризованный.

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

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

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

Колоночные

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

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

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

В науке о данных часто бывает, что каждая колонка представляет определенную характеристику. Как специалист по данным я часто тренирую свои модели на подмножествах характеристик и проверяю отношения между ними и оценками (корреляция, дисперсия, значимость). То же подходит и для логов— в них зачастую множество полей, но при каждом запросе используются только некоторые. Например:

Cassandra.

Строчная и колоночная базы данных

Ссылочная целостность

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

Как при этом не допустить появления \»болтающихся в воздухе\» строк дочерней таблицы? Для этого существуют правила ссылочной целостности ON UPDATE и ON DELETE, которые, по стандарту SQL 92, могут содержать следующие инструкции:

Более интересные моменты возникают, когда мы удаляем или изменяем строки родительской таблицы. Как при этом не допустить появления \»болтающихся в воздухе\» строк дочерней таблицы? Для этого существуют правила ссылочной целостности ON UPDATE и ON DELETE, которые, по стандарту SQL 92, могут содержать следующие инструкции:

• CASCADE — обеспечивает автоматическое выполнение в дочерней таблице тех же изменений, которые были сделаны в родительском ключе. Если родительский ключ был изменен — ON UPDATE CASCADE обеспечит точно такие же изменения внешнего ключа в дочерней таблице. Если строка родительской таблицы была удалена, ON DELETE CASCADE обеспечит удаление всех соответствующих строк дочерней таблицы.
• SET NULL — при удалении строки родительской таблицы ON DELETE SET NULL установит значение NULL во всех столбцах вторичного ключа в соответствующих строках дочерней таблицы. При изменении родительского ключа ON UPDATE SET NULL установит значение NULL в соответствующих столбцах соответствующих строк (о как:) дочерней таблицы.
• SET DEFAULT — работает аналогично SET NULL, только записывает в соответствующие ячейки не NULL, а значения, установленные по умолчанию.
• NO ACTION (установлено по умолчанию) — при изменении родительского ключа никаких действий с внешним ключом в дочерней таблице не производится. Но если изменение значений родительского ключа приводит к нарушению ссылочной целосности (т.е. к появлению «висящих в воздухе» строк дочерней таблицы), то СУБД не даст произвести такие изменения родительской таблицы.

Ну а сейчас — от общего к частному.

Определение ключевых полей

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

В Microsoft Access можно выделить три типа ключевых полей: счетчик, простой ключ и составной ключ. Рассмотрим каждый из этих типов.

Для создания ключевого поля типа Счетчик необходимо в режиме Конструктора таблиц:

1. Включить в таблицу поле счетчика.
2. Задать для него автоматическое увеличение на 1.
3. Указать это поле в качестве ключевого путем нажатия на кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).

Если до сохранения созданной таблицы ключевые поля не были определены, то при сохранении будет выдано сообщение о создании ключевого поля. При нажатии кнопки Да (Yes) будет создано ключевое поле счетчика с именем Код (ID) и типом данных Счетчик (AutoNumber).

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

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

1. Открыть таблицу в режиме Конструктора.
2. Выделить поля, которые необходимо определить как ключевые.
3. Нажать кнопку Ключевое поле (Primary Key) на панели инструментов Конструктор таблиц (Table Design).

Для составного ключа существенным может оказаться порядок образующих ключ полей. Сортировка записей осуществляется в соответствии с порядком ключевых полей в окне Конструктора таблицы. Если необходимо указать другой порядок сортировки без изменения порядка ключевых полей, то сначала нужно определить ключ, а затем нажать кнопку Индексы (Indexes) на панели инструментов Конструктор таблиц (Table Design). Затем в появившемся окне Индексы (Indexes) нужно указать другой порядок полей для индекса с именем Ключевое поле (Primary Key).

Рассмотрим в качестве примера применения составного ключа таблицу «Заказано» (OrderDetails) базы данных (Northwind) (рис. 2.23).

В данном случае в качестве составного ключа используются поля «Код заказа» (OrderlD) и «КодТовара» (ProductID), т. к. ни одно из этих полей в отдельности не гарантирует уникальность записи. При этом в таблице выводится не код товара, а наименование товара, т. к. поле «КодТовара» (ProductID) данной таблицы содержит подстановку из таблицы «Товары» (Products), а значения полей «КодТовара» (ProductID) этих таблиц связаны отношением «один-ко-многим» (одной записи таблицы «Товары» (Products) может соответствовать несколько записей таблицы «Заказано» (OrderDetails)). Оба поля могут содержать повторяющиеся значения. Так, один заказ может включать в себя несколько товаров, а в разные заказы могут включаться одинаковые товары. В то же время сочетание полей «КодЗаказа» (OrderlD) и «КодТовара» (ProductID) однозначно определяет каждую запись таблицы «Заказы» (OrderDetails).

Чтобы изменить ключ, необходимо:

1. Открыть таблицу в режиме Конструктора.
2. Выбрать имеющиеся ключевые поля.
3. Нажать на кнопку Ключевое поле (Primary Key), при этом кнопка должна принять положение Выкл., а из области выделения должны исчезнуть значки ключевого поля.
4. Выбрать поле, которое необходимо сделать ключевым.
5. Нажать на кнопку Ключевое поле (Primary Key). При этом в области выделения должен появиться значок ключевого поля.

Чтобы удалить ключ, необходимо:

1. Открыть таблицу в режиме Конструктора.
2. Выбрать имеющееся ключевое поле (ключевые поля).
3. Нажать на кнопку Ключевое поле (Primary Key), при этом кнопка должна принять положение Выкл., а из области выделения должен исчезнуть значок (значки) ключевого поля.

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

• в ней нет одинаковых строк;
• все столбцы (атрибуты) в таблице должны иметь разные имена;
• элементы в пределах одной колонки имеют одинаковый тип (строка, число, дата);
• порядок следования строк в таблице может быть произвольным.

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

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

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

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

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

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

SQL PRIMARY KEY в CREATE TABLE

Следующий SQL создает первичный ключ в столбце «ID» при создании таблицы «Persons»:

MySQL:

CREATE TABLE Persons
(
    ID int NOT NULL,
   
LastName varchar(255) NOT NULL,
   
FirstName varchar(255),
   
Age int,
   
PRIMARY KEY (ID)
);

SQL Server / Oracle / MS Access:

CREATE TABLE Persons
(
    ID int NOT NULL PRIMARY KEY,
   
LastName varchar(255) NOT NULL,
   
FirstName varchar(255),
   
Age int
);

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

MySQL / SQL Server / Oracle / MS Access:

CREATE TABLE Persons
(
    ID int NOT NULL,
   
LastName varchar(255) NOT NULL,
   
FirstName varchar(255),
   
Age int,
   
CONSTRAINT PK_Person PRIMARY KEY (ID,LastName)
);

Примечание: В приведенном выше примере существует только один первичный ключ (PK_Person).
Однако значение первичного ключа состоит из TWO COLUMNS (ID + LastName).

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 Комментарии

Выводы

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