ON [PRIMARY] ne anlama geliyor?

237

Bir SQL kurulum komut dosyası oluşturuyorum ve başka birinin komut dosyasını örnek olarak kullanıyorum. İşte senaryo örneği:

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] komutunun ne yaptığını bilen var mı?

— Icono123
kaynak

248

Microsoft SQL Server'da bir veritabanı oluşturduğunuzda, depolama alanının birden çok yerde, dizinde veya diskte oluşturulduğu birden çok dosya grubunuz olabilir. Her dosya grubu adlandırılabilir. PRIMARY dosya grubu her zaman oluşturulan varsayılan gruptur ve böylece verdiğiniz SQL PRIMARY dosya grubundaki tablonuzu oluşturur.

Söz diziminin tamamı için MSDN'ye bakın .

— blowdart
kaynak

153

Bu aynı zamanda genellikle işe yaramaz olduğu ve komut dosyasından güvenle kaldırılabileceği anlamına gelir .

— MGOwen

Evet, aynı şekilde, değişken başlatmaları 0 ve false olarak atlayabilirsiniz, çünkü bu sadece varsayılan, değil mi?

— Mark Sowul

12

@MarkSowul Performansı optimize etmek için bunu kullanmak için iyi bir nedeniniz yoksa, evet, atlamak ve varsayılanın gerçekleşmesine izin vermek iyidir. (Bu nedenle "genellikle" MGOwen dahil edilir.) Değişkenleri başlatmak 0veya falsekodunuzun bilinen bir durumda çalışmasını sağlamakla ilgilidir, bu da bir optimizasyon endişesi değil, mantıklı ve doğrulukla ilgilidir.

— jpmc26

3

ON PRIMARYSözdizimini komut dosyasında iki kez görüyorum - biri tablo için diğeri tablo kısıtlaması için. Depolama açısından tablonun kısıtlanması durumunda ne ifade eder? Bana ilgisiz veya gereksiz geliyor. Sözdizimsel olarak, tablo düzeyinde bir kez belirtmek yeterli olmalı ya da tabloyu PRIMARY dosya grubu ve tablo kısıtlama verisi PRIMARY olmayan dosya grubunda saklamak gerçekten mümkün mü?

— RBT

1

İşte gerçek MSDN bağlantısı. Yanıttaki kişi artık çalışmıyor ve gönderiyi düzenleyemiyorum!

— shekhar

38

Oluşturduğunuz nesnenin hangi dosya grubunda bulunduğunu ifade eder. Böylece Birincil dosya grubunuz sunucunuzun D: \ sürücüsünde bulunabilir. daha sonra Dizinler adlı başka bir dosya grubu oluşturabilirsiniz. Bu dosya grubu sunucunuzun E: \ sürücüsünde bulunabilir.

— codingbadger
kaynak

Tabloyu PRIMARY dosya grubu ve tablo kısıtı veya indeks veri yapısını farklı bir dosya grubunda saklarsam olumsuz bir performans etkisi olur mu?

— RBT

@RBT bu etkileyebilir çok sayıda değişken ve "Duruma göre ama ..." bkz başlayacak cevaplar genellikle çok var dba.stackexchange.com/questions/2626/... ve ilgili soruları

— codingbadger

16

ON [PRIMARY], "Birincil" dosya grubunda yapılar oluşturur. Bu durumda, birincil anahtar dizini ve tablo, veritabanı içindeki "Birincil" dosya grubuna yerleştirilir.

— Mark S.
kaynak

7

Mark S.'nin görevinde neler söylediğine çok önemli bir not eklemek için. Soruda belirtilen SQL Komut Dosyasında veri satırlarınızı ve dizin veri yapısını depolamak için ASLA iki farklı dosya grubundan söz edemezsiniz.

Bunun nedeni, bu durumda oluşturulan dizinin birincil anahtar sütununuzda kümelenmiş bir dizin olmasından kaynaklanmaktadır. Kümelenmiş dizin verileri ve tablonuzun veri satırları ASLA farklı dosya gruplarında olamaz .

Yani veritabanınızda PRIMARY ve SECONDARY gibi iki dosya grubunuz olması durumunda, aşağıda belirtilen komut dosyası [SECONDARY], tablo verileriniz için farklı bir dosya grubundan ( ) bahsetmiş olmama rağmen, satır verilerinizi ve kümelenmiş dizin verilerinizi hem PRIMARY dosya grubunun kendisinde depolar. . Daha ilginç bir şekilde komut dosyası da başarılı bir şekilde çalışıyor (iki farklı dosya grubu verdiğim gibi bir hata vermesini beklediğimde: P). SQL Server, sahne arkasındaki hileyi sessizce ve akıllıca yapar.

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

NOT: Dizininiz YALNIZCA yaratılan dizin doğada kümelenmemişse farklı bir dosya grubunda bulunabilir .

Kümelenmemiş bir dizin oluşturan aşağıdaki komut [SECONDARY]dosyası, tablo verileri zaten [PRIMARY]dosya grubunda bulunuyorsa, dosya grubunda oluşturulacaktır:

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

Kümelenmemiş dizinleri farklı bir dosya grubunda depolamanın, sorgularınızın daha iyi performans göstermesine nasıl yardımcı olabileceği hakkında daha fazla bilgi edinebilirsiniz. İşte böyle bir bağlantı.

— MHK
kaynak