SqlServer i nvarchar (max)

Question

Obecnie szukamy ustawień naszych kolumn ciągów do nvarchar(max) zamiast określania określonej długości, aby zapobiec problemom tam, gdzie może być za mało miejsca w bazie danych do przechowywania ciągu znaków. Zastanawiam się tylko, czy to jest dobre, czy może to powodować problemy, ponieważ było to w porządku, to dlaczego określić długość, jak nvarchar(10), a nie nvarchar(max). Używamy także bardzo dużo, ponieważ nie wiemy, ile danych binarnych będziemy potrzebować, więc nie jestem pewien, jak bardzo jest to efekt, ponieważ nasze wstawki nie są tak szybkie, jak myślę, że powinny być. To jest przykładowa tabela:

CREATE TABLE [dbo].[SAMPLETABLE] ( 
[ID] [uniqueidentifier] NOT NULL, 
[FIELD1] [int] NOT NULL, 
[FIELD2] [nvarchar] (2000) NULL, 
[FIELD3] [nvarchar] (max) NULL, 
[FIELD4] [uniqueidentifier] NULL, 
[FIELD5] [int] NULL, 
[FIELD6] [nvarchar] (2000) NULL, 
[FIELD7] [varbinary] (max) NULL, 
[FIELD8] [varbinary] (max) NULL, 
[FIELD9] [varbinary] (max) NULL, 
[FIELD10] [uniqueidentifier] NULL, 
[FIELD11] [nvarchar] (2000) NULL, 
[FIELD12] [varbinary] (max) NULL, 
[FIELD13] [varbinary] (max) NULL, 
[FIELD14] [bit] NULL, 
[FIELD15] [uniqueidentifier] NULL, 
[FIELD16] [varbinary] (max) NULL, 
[FIELD17] [bit] NULL, 
[FIELD18] [tinyint] NULL, 
[FIELD19] [datetime] NULL, 
[FIELD20] [nvarchar] (2000) NULL, 
PRIMARY KEY CLUSTERED 
( 
    [ID] ASC 
) 
) ON [PRIMARY] 

GO 

Biorąc pod uwagę, że projekt stół jak i zmieniając nvarchar(2000) do nvarchar(max) by to zrobić rzeczy gorszy (lub lepszy)? Czy sqlserver nie patrzy na takie projekty?

Answer 1

Jeśli jesteś zadowolony z J. Random Developer, 6 miesięcy w dół, aby wstawić dzieło Szekspira do każdej kolumny, to dobrze.

Dla mnie duża część modelowania danych poważnie myśli o tym, jakie dane chcę zezwolić w każdej kolumnie i jakie dane chcę zabronić. Następnie stosuję odpowiednie ograniczenia CHECK, aby osiągnąć te ograniczenia (jak zezwala na to najlepszy serwer SQL). Posiadanie rozsądnej kontroli długości dostępnej "za darmo" zawsze wydawało się premią.

---

Ty też nie robi wiele „przyszłość proofing” - zmiana długości (n) kolumny varchar do większej wartości w późniejszym terminie jest, moim zdaniem, jedynie operacja meta-danych. Powiedziałbym więc, żeby odpowiednio dopasować kolumny do danych, z którymi masz zamiar się dzisiaj zetknąć (i dobrze, przez następny rok lub mniej). Jeśli chcesz je później rozwinąć, zajmie to kilka sekund.

Answer 2

Odpowiedź jest taka sama, jak odpowiedź "Dlaczego muszę podać int, gdy mogę przechowywać wszystkie liczby jako ciągi?" - ponieważ pomaga:

• efektywność prędkości.
• efektywność przechowywania.
• intencja autora/architekta.
• obniża błąd danych, ponieważ zmieści się tylko pewien rodzaj danych.

Ale to nie spowoduje żadnych oczywistych "problemów" natychmiast, ponieważ nvarchar (10) jest podzbiorem nvarchar (max).

Answer 3

Miejmy nadzieję, że nie należy używać do wyszukiwania lub kolumny mają unikalne wartości ...

Indeksy nie może przekraczać 900 bajtów szeroki Więc może nigdy prawdopodobnie utworzyć indeks. Jest jeden minus: ponieważ daje

• naprawdę złe szukają wydajność
• żadnych ograniczeń unique

Można go obejść z kolumną komputerowej ale dlaczego nie zapisać swój potrzebę?

Answer 4

Przełączanie z typów w rzędzie na typy typu BLOB to zawsze duża decyzja.Trzeba internalizacji że typy BLOB (VARCHAR(MAX), NVARCHAR(MAX) i VARBINARY(MAX)) to zupełnie inny typ wewnętrznie z typów w wierszu:

• Idą do innej jednostce alokacji, zobacz Table and Index Organization
• Oni nie mogą być indeksowane
• podlegają różnych opcji przechowywania w sp_tableoption
• Wykorzystują one zupełnie inną ścieżkę kodu manipulacja, patrz Performance comparison of varchar(max) vs. varchar(N)
• op online eracje nie są dozwolone w tabelach z obiektami BLOB (zobacz Wyjątek pod adresem ALTER INDEX ... REBUILD ... WITH (ONLINE= ON). Liczyć, że skoro tabela już BLOB, to nie będzie problemu

Więc przełączania wszystkie kolumny typu BLOB może przynieść wiele efektów ubocznych nie zostały uznane: niemożność indeksu kolumny BLOB, brak operacji online, ogólne pogorszenie wydajności z powodu wolniejszego kodu BLOB itp. Najpoważniejszą przeszkodą może być fakt, że nie będzie można indeksować kolumn po ich utworzeniu BLOB. Jeśli nie jest to korek wystawowy, musisz przetestować i zmierzyć wpływ wydajności.

Obawy modelujące dane inne zostały poruszone są w ogóle ważne, ale rozumiem, że często w świecie rzeczywistym teoria działa tylko w teorii ...

Answer 5

Oto ta sama odpowiedź dałem do innego faceta, który chciał niekończące się tabele:

Database alternative to MySQL made for millions of TABLES

ten kawałek powyżej jest mniejszy niż optymalny projekt dla każdej relacyjnej przechowywania danych. Pop idzie łasicą danych: po prostu wybierz jedną z nich, aby uzyskać żądane dane.

Być może rozwiązanie sql nie działa lepiej, więc możesz mieć dynamiczne dane i nie martwić się o limity kolumn.

Myślę, że jeśli zamierzamy odpowiadać na pytania, uważam, że powinniśmy oferować najlepsze/lepsze praktyki, gdy istnieją alternatywy wobec złego projektu.

Pomyśl o facecie nadchodzących po KM jak wspomniano powyżej

Answer 6

w moim doświadczeniu nie wiele 2000 znaków długie pola skończyć indeksowane chociaż. Myślę, że znacznie lepiej jest używać nvarchar (max) niż jakiejś arbitralnej długości, która może wymagać obcięcia danych, jeśli nie jest wystarczająco długa.

Przykładem, który zobaczyłem, jest tabela dziennika błędów, w której projektanci tabel nie byli przygotowani do przechowywania stosu wywołań w polu nvarchar (maks.), Więc zapisali pierwsze n-tysięczne znaki, co spowodowało okrojone stosy połączeń z najciekawszymi sekcjami brakuje.