Что значит 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]?

Icono123
источник

Ответы:

248

Когда вы создаете базу данных в Microsoft SQL Server, у вас может быть несколько файловых групп, где хранилище создается в нескольких местах, каталогах или дисках. Каждая файловая группа может быть названа. Основная группа файлов является группой по умолчанию, которая создается всегда, и поэтому указанный вами SQL создает вашу таблицу НА ОСНОВНОЙ группе файлов.

См MSDN для полного синтаксиса.

blowdart
источник
153
Это также означает, что обычно это бесполезно и может быть безопасно удалено из сценария.
MGOwen
Да, точно так же вы можете просто опустить инициализацию переменных в 0 и false, потому что это просто значение по умолчанию, верно?
Марк Совул
12
@MarkSowul Если у вас нет веских оснований использовать это для оптимизации производительности, да, это нормально, если опустить его и позволить по умолчанию произойти. (Таким образом, «обычно» включена MGOwen.) Инициализация переменных 0или falseо обеспечении того , чтобы ваш код работает в известном состоянии, что является логичной и правильностью заботы , а не оптимизации беспокойства.
jpmc26
3
Я вижу ON PRIMARYсинтаксис дважды в скрипте - один для таблицы и другой для ограничения таблицы. Что это означает в случае ограничения таблицы с точки зрения хранения? Это звучит неуместно или избыточно для меня. Синтаксически, должно быть достаточно упомянуть об этом один раз на уровне таблицы или действительно возможно сохранить таблицу в группе файлов PRIMARY и данные об ограничениях таблиц в группе файлов NIMPIMARY?
RBT
1
Вот фактическая ссылка MSDN . Тот, что в ответе, больше не работает, и я не могу редактировать сообщение!
шехар
38

Он указывает на то, в какой файловой группе находится создаваемый вами объект. Таким образом, ваша основная файловая группа может находиться на диске D: \ вашего сервера. Вы могли бы тогда создать другую файловую группу под названием Индексы. Эта файловая группа может находиться на диске E: \ вашего сервера.

codingbadger
источник
Будет ли это иметь негативное влияние на производительность, если я сохраню таблицу в основной группе файлов, а ограничение таблицы или структуру данных индекса в другой группе файлов?
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
источник