Co oznacza ON [PRIMARY]?

Tworzę skrypt instalacyjny SQL i używam skryptu innej osoby jako przykładu. Oto przykład skryptu:

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

Czy ktoś wie, co robi polecenie ON [PRIMARY]?

Podczas tworzenia bazy danych w Microsoft SQL Server możesz mieć wiele grup plików, w których pamięć jest tworzona w wielu miejscach, katalogach lub dyskach. Każda grupa plików może mieć nazwę. Grupa plików PODSTAWOWA jest grupą domyślną, która jest zawsze tworzona, więc podany SQL tworzy tabelę NA grupie plików PODSTAWOWYCH.

Zobacz pełną składnię MSDN .

Odnosi się do tego, na której grupie plików znajduje się tworzony obiekt. Tak więc podstawowa grupa plików może znajdować się na dysku D: \ serwera. możesz następnie utworzyć inną grupę plików o nazwie Indeksy. Ta grupa plików może znajdować się na dysku E: \ twojego serwera.

ON [PODSTAWOWY] utworzy struktury w grupie plików „Podstawowy”. W takim przypadku indeks klucza podstawowego i tabela zostaną umieszczone w grupie plików „Podstawowy” w bazie danych.

Aby dodać bardzo ważną notatkę o tym, co Mark S. wspomniał w swoim poście. W konkretnym skrypcie SQL wspomnianym w pytaniu NIGDY nie można wymieniać dwóch różnych grup plików do przechowywania wierszy danych i struktury danych indeksu.

Powodem tego jest fakt, że indeks tworzony w tym przypadku jest klastrowanym indeksem w kolumnie klucza podstawowego. Dane indeksu klastrowego i wiersze danych tabeli NIGDY nie mogą znajdować się w różnych grupach plików .

Więc jeśli masz dwie grupy plików w bazie danych, np. PODSTAWOWY i WTÓRNY, to niżej wymieniony skrypt będzie przechowywać dane wiersza i dane indeksu klastrowego zarówno w samej grupie plików PODSTAWOWYCH, chociaż wspomniałem o innej grupie plików ( [SECONDARY]) dla danych tabeli . Co ciekawsze, skrypt również działa poprawnie (gdy spodziewałem się, że spowoduje błąd, ponieważ podałem dwie różne grupy plików: P). SQL Server rozwiązuje ten problem za cicho i elegancko.

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

UWAGA: Twój indeks może znajdować się w innej grupie plików TYLKO, jeśli tworzony indeks nie ma charakteru klastrowego .

Poniższy skrypt, który tworzy indeks nieklastrowany, zostanie utworzony w [SECONDARY]grupie plików, gdy dane tabeli już znajdują się w [PRIMARY]grupie plików:

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

Możesz uzyskać więcej informacji o tym, jak przechowywanie indeksów nieklastrowanych w innej grupie plików może pomóc w lepszej wydajności zapytań. Oto jeden taki link.