Що означає ON [PRIMARY]?

237

Я створюю сценарій настройки SQL і використовую чужий сценарій як приклад. Ось приклад сценарію:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[be_Categories](
    [CategoryID] [uniqueidentifier] ROWGUIDCOL  NOT NULL CONSTRAINT [DF_be_Categories_CategoryID]  DEFAULT (newid()),
    [CategoryName] [nvarchar](50) NULL,
    [Description] [nvarchar](200) NULL,
    [ParentID] [uniqueidentifier] NULL,
 CONSTRAINT [PK_be_Categories] PRIMARY KEY CLUSTERED 
(
    [CategoryID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

Хтось знає, що робить команда ON [PRIMARY]?

— Іконо123
джерело

248

Під час створення бази даних у Microsoft SQL Server у вас може бути декілька груп файлів, де зберігання створюється в декількох місцях, каталогах або на дисках. Кожна група файлів може бути названа. Група файлів PRIMARY - це за замовчуванням, яка завжди створюється, і тому заданий вами SQL створює вашу таблицю НА ПЕРВІЙНІЙ групі файлів.

Дивіться MSDN для повного синтаксису.

— удар
джерело

153

Це також означає, що це зазвичай марно і його можна безпечно видалити зі сценарію.

— MGOwen

Так, таким же чином ви можете просто опустити ініціалізацію змінних до 0 та false, тому що це просто за замовчуванням, правда?

— Марк Совул

12

@MarkSowul Якщо ви не маєте вагомих причин використати це для оптимізації продуктивності, так, це нормально опустити його і дозволити відбутися за замовчуванням. (Звідси включено "звичайно" MGOwen.) Ініціалізація змінних 0або falseполягає у забезпеченні роботи вашого коду у відомому стані, що є проблемою логіки та коректності, а не проблемою оптимізації.

— jpmc26

3

ON PRIMARYСинтаксис я бачу двічі в сценарії - один для таблиці та інший для обмеження таблиці. Що це означає у випадку обмеження таблиці щодо зберігання? Для мене це звучить неважливо або надмірно. Синтаксично повинно було бути достатньо один раз згадати його на рівні таблиці, чи дійсно можливо зберегти таблицю в групі PRIMARY файлів та даних обмеження таблиці в НЕПРИМЕЧНІЙ групі файлів?

— RBT

1

Ось власне посилання MSDN . Той, що у відповіді більше не працює, і я не можу редагувати публікацію!

— шекхар

38

Він позначає, на якій файловій групі знаходиться об'єкт, який ви створюєте. Таким чином, ваша групова файлова група може перебувати на диску D: \ вашого сервера. потім можна створити іншу групу файлів під назвою "Індекси". Ця група файлів може перебувати на диску E: \ вашого сервера.

— кодування
джерело

Чи матиме це негативний вплив на ефективність, якщо я зберігатиму таблицю на ПЕРВІЙНІй групі файлів і обмеженнях таблиці або структурі даних індексу для іншої групи файлів?

— RBT

@RBT Є багато змінних , які можуть вплинути на це, і , як правило багато відповідей буде починатися з «Це залежить , але ...» см dba.stackexchange.com/questions/2626 / ... і пов'язані з ними питання

— codingbadger

16

ON [PRIMARY] створить структури у групі файлів "Первинний". У цьому випадку індекс первинного ключа та таблиця будуть розміщені у групі файлів "Первинний" всередині бази даних.

— Марк С.
джерело

7

Щоб додати дуже важливу примітку про те, що Марк С. згадав у своєму дописі. У конкретному SQL-скрипті, який згадувався у запитанні, НІКОЛИ не можна згадувати дві різні групи файлів для зберігання ваших рядків даних та структури даних індексу.

Причиною тому, що індекс, що створюється в цьому випадку, є кластерним Індексом у стовпці основного ключа. Кластеризовані дані індексу та рядки даних вашої таблиці НІКОЛИ не можуть знаходитись у різних групах файлів .

Тож у випадку, якщо у вашій базі даних є дві групи файлів, наприклад PRIMARY та SECONDARY, нижче вказаний сценарій зберігатиме дані про рядки та кластеризовані дані індексу як у самій PRIMARY файловій групі, хоча я згадував іншу групу файлів ( [SECONDARY]) для даних таблиці . Що ще цікавіше, сценарій також працює успішно (коли я очікував, що він помилиться, оскільки я дав дві різні групи файлів: P). SQL Server робить фокус поза сценою мовчки і спритно.

CREATE TABLE [dbo].[be_Categories](
    [CategoryID] [uniqueidentifier] ROWGUIDCOL  NOT NULL CONSTRAINT [DF_be_Categories_CategoryID]  DEFAULT (newid()),
    [CategoryName] [nvarchar](50) NULL,
    [Description] [nvarchar](200) NULL,
    [ParentID] [uniqueidentifier] NULL,
 CONSTRAINT [PK_be_Categories] PRIMARY KEY CLUSTERED 
(
    [CategoryID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [SECONDARY]
GO

ПРИМІТКА: Ваш індекс може містити ТОЛЬКО іншу групу файлів, якщо створений індекс некластеризований .

Сценарій нижче, який створює некластеризований індекс, буде створений [SECONDARY]замість файлової групи, коли дані таблиці вже знаходяться у [PRIMARY]групі файлів:

CREATE NONCLUSTERED INDEX [IX_Categories] ON [dbo].[be_Categories]
(
    [CategoryName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [Secondary]
GO

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

— RBT
джерело