Что означает ON [PRIMARY]?

Я создаю SQL-настройку script, и я использую кого-то еще script в качестве примера. Вот пример script:

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]?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

Добавить очень важное замечание о том, что упоминал Марк С. в своем посте. В конкретном SQL Script, который упоминался в вопросе, вы НИКОГДА не упоминаете две разные группы файлов для хранения ваших строк данных и структуры данных индекса.

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

Итак, если у вас есть две группы файлов в вашей базе данных, например. PRIMARY и SECONDARY, а затем ниже упомянутые Script будут хранить ваши данные строк и данные с кластеризованным индексом как в самой группе файлов PRIMARY, даже если я упомянул о другой группе файлов ([SECONDARY]) для данных таблицы. Более интересно, что Script работает успешно (когда я ожидал, что он даст ошибку, поскольку я дал две разные группы файлов: 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

ПРИМЕЧАНИЕ: Ваш индекс может находиться только в другой группе файлов, если создаваемый индекс не кластеризуется в природе.

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

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