Cosa significa ON [PRIMARY]?

237

Sto creando uno script di installazione SQL e sto usando lo script di qualcun altro come esempio. Ecco un esempio dello 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

Qualcuno sa cosa fa il comando ON [PRIMARY]?

— Icono123
fonte

248

Quando si crea un database in Microsoft SQL Server, è possibile avere più gruppi di file, in cui l'archiviazione viene creata in più posizioni, directory o dischi. È possibile assegnare un nome a ciascun gruppo di file. Il gruppo di file PRIMARY è quello predefinito, che viene sempre creato, quindi l'SQL che hai fornito crea la tua tabella sul gruppo di file PRIMARY.

Vedi MSDN per la sintassi completa.

— blowdart
fonte

153

Questo significa anche che di solito è inutile e può essere rimosso in modo sicuro dallo script.

— MGOwen

Sì, allo stesso modo puoi semplicemente omettere le inizializzazioni variabili su 0 e false, perché è solo l'impostazione predefinita, giusto?

— Mark Sowul il

12

@MarkSowul A meno che tu non abbia una buona ragione per usarlo per ottimizzare le prestazioni, sì, va bene ometterlo e lasciare che il default avvenga. (Da qui il "solito" MGOwen incluso.) Inizializzare le variabili 0o falsegarantire che il codice funzioni in uno stato noto, che è un problema logico e di correttezza e non un problema di ottimizzazione.

— jpmc26,

3

Vedo la ON PRIMARYsintassi due volte nello script: uno per la tabella e un altro per il vincolo della tabella. Che cosa significa in caso di vincolo di tabella in termini di archiviazione? Sembra irrilevante o ridondante per me. Sintatticamente, avrebbe dovuto essere sufficiente menzionarlo una volta a livello di tabella o è davvero possibile memorizzare la tabella nel gruppo di file PRIMARY e i dati di vincolo della tabella nel gruppo di file NON PRIMARY?

— RBT,

1

Ecco l'effettivo collegamento MSDN . Quello nella risposta non funziona più e non posso modificare il post!

— Shekhar,

38

Si riferisce a quale filegroup risiede l'oggetto su cui si sta creando. Quindi il tuo filegroup primario potrebbe risiedere sull'unità D: \ del tuo server. è quindi possibile creare un altro filegroup chiamato Indexes. Questo filegroup potrebbe risiedere sull'unità E: \ del server.

— codingbadger
fonte

Avrà un impatto negativo sulle prestazioni se memorizzo la tabella nel gruppo di file PRIMARY e il vincolo della tabella o la struttura dei dati di indice in un diverso gruppo di file?

— RBT,

@RBT Ci sono molte variabili che possono influenzare questo, e di solito molte risposte inizieranno con "Dipende ma ..." vedi dba.stackexchange.com/questions/2626/… e domande correlate

— codingbadger

16

ON [PRIMARY] creerà le strutture nel filegroup "Primario". In questo caso, l'indice della chiave primaria e la tabella verranno posizionati nel filegroup "Principale" all'interno del database.

— Mark S.
fonte

7

Per aggiungere una nota molto importante su ciò che Mark S. ha menzionato nel suo post. Nello specifico script SQL menzionato nella domanda non è MAI possibile menzionare due diversi gruppi di file per l'archiviazione delle righe dei dati e della struttura dei dati dell'indice.

Il motivo è dovuto al fatto che l'indice creato in questo caso è un indice cluster nella colonna chiave primaria. I dati dell'indice cluster e le righe di dati della tabella non possono MAI trovarsi in gruppi di file diversi .

Quindi nel caso in cui tu abbia due gruppi di file nel tuo database, ad esempio PRIMARY e SECONDARY, lo script sotto menzionato memorizzerà i tuoi dati di riga e i dati dell'indice cluster sia sul gruppo di file PRIMARY stesso anche se ho menzionato un diverso gruppo di file ( [SECONDARY]) per i dati della tabella . Ancora più interessante anche lo script funziona correttamente (quando mi aspettavo che generasse un errore dato che avevo dato due diversi gruppi di file: P). SQL Server fa il trucco dietro la scena in modo silenzioso e intelligente.

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: L'indice può risiedere in un gruppo di file diverso SOLO se l'indice che si sta creando non ha cluster .

Lo script seguente che crea un indice non cluster verrà creato nel [SECONDARY]gruppo di file invece quando i dati della tabella risiedono già nel [PRIMARY]gruppo di file:

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

È possibile ottenere ulteriori informazioni su come l'archiviazione di indici non cluster in un gruppo di file diverso può aiutare le query a funzionare meglio. Ecco uno di questi link.

— RBT
fonte