O que significa ON [PRIMARY]?

Estou criando um script de instalação do SQL e estou usando o script de outra pessoa como exemplo. Aqui está um exemplo do 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

Alguém sabe o que o comando ON [PRIMARY] faz?

Ao criar um banco de dados no Microsoft SQL Server, você pode ter vários grupos de arquivos, nos quais o armazenamento é criado em vários locais, diretórios ou discos. Cada grupo de arquivos pode ser nomeado. O grupo de arquivos PRIMARY é o padrão, que é sempre criado; portanto, o SQL que você forneceu cria sua tabela no grupo de arquivos PRIMARY.

Veja MSDN para a sintaxe completa.

Refere-se a qual grupo de arquivos o objeto em que você está criando reside. Portanto, seu grupo de arquivos principal pode residir na unidade D: \ do seu servidor. você pode criar outro grupo de arquivos chamado índices. Este grupo de arquivos pode residir na unidade E: \ do seu servidor.

ON [PRIMARY] criará as estruturas no grupo de arquivos "Primário". Nesse caso, o índice da chave primária e a tabela serão colocados no grupo de arquivos "Primário" no banco de dados.

Para adicionar uma nota muito importante sobre o que Mark S. mencionou em seu post. No script SQL específico mencionado na pergunta, NUNCA é possível mencionar dois grupos de arquivos diferentes para armazenar suas linhas de dados e a estrutura de dados do índice.

O motivo disso se deve ao fato de o índice que está sendo criado nesse caso ser um índice agrupado em sua coluna de chave primária. Os dados do índice clusterizado e as linhas de dados da sua tabela NUNCA podem estar em diferentes grupos de arquivos .

Portanto, caso você tenha dois grupos de arquivos no seu banco de dados, por exemplo, PRIMARY e SECONDARY, o script abaixo mencionado armazenará seus dados de linha e dados de índice em cluster no próprio grupo de arquivos PRIMARY, embora eu tenha mencionado um grupo de arquivos diferente ( [SECONDARY]) para os dados da tabela . O mais interessante é que o script também é executado com êxito (quando eu esperava que desse um erro, como havia dado dois grupos de arquivos diferentes: P). O SQL Server faz o truque nos bastidores de maneira silenciosa e inteligente.

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

NOTA: Seu índice pode residir apenas em um grupo de arquivos diferente se o índice que está sendo criado não tiver um cluster de natureza .

O script abaixo que cria um índice não agrupado em cluster será criado no [SECONDARY]grupo de arquivos, quando os dados da tabela já residirem no [PRIMARY]grupo de arquivos:

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

Você pode obter mais informações sobre como o armazenamento de índices não agrupados em cluster em um grupo de arquivos diferente pode ajudar no desempenho de suas consultas. Aqui está um desses links.