sql >> Databáze >  >> RDS >> Sqlserver

Rozdíl mezi různými typy řetězců v SQL Server?

text a ntext jsou zastaralé, takže je na chvíli vynechme. Pro to, co zbylo, existují 3 rozměry:

  • Unicode (UCS-2) vs. non-unicode:N před názvem označuje Unicode
  • Pevná délka vs. proměnná délka:var označuje proměnnou, jinak pevnou
  • In-row vs. BLOB:(max) jak délka označuje BLOB, jinak je to hodnota v řádku

Takže s tímto můžete číst význam jakéhokoli typu:

  • CHAR(10) :je řádková pevná délka bez Unicode velikosti 10
  • NVARCHAR(256) :je Unicode s proměnnou délkou v řádku o velikosti až 256
  • VARCHAR(MAX) :je objekt BLOB s proměnnou délkou bez Unicode

Zastaralé typy text a ntext odpovídají novým typům varchar(max) a nvarchar(max) respektive.

Když přejdete na podrobnosti, význam in-row vs. BLOB rozmaže na malé délky, jak motor může optimalizovat úložiště a vytáhnout BLOB v řádku nebo vložit hodnotu v řádku do alokační jednotky 'small BLOB', ale to je jen detail implementace. Viz Organizace tabulek a indexů .

Z programovacího hlediska všechny typy:CHAR , VARCHAR , NCHAR , NVARCHAR , VARCHAR(MAX) a NVARCHAR(MAX) , podporují jednotné řetězcové API:Funkce řetězců . Staré, zastaralé typy TEXT a NTEXT ne podporují toto API, mají samostatné, zoufalé, TEXT API pro manipulaci. Neměli byste používat zastaralé typy.

Typy BLOB podporují účinné aktualizace na místě pomocí UPDATE table SET column.WRITE(@value, @offset) syntaxe.

Rozdíl mezi typy s pevnou délkou a proměnnou délkou zmizí při kompresi řádků v tabulce. S povolenou kompresí řádků jsou typy pevné délky a proměnné délky uloženy ve stejném formátu a koncové mezery se neukládají na disk, viz Implementace komprese řádků . Všimněte si, že komprese stránky znamená kompresi řádků.



  1. Datový typ pro ukládání IP adresy na SQL Server

  2. Načítání tabulky mysql do pythonu trvá velmi dlouho ve srovnání s R

  3. platný UUID není platný UUID

  4. Jak donutím Postgres, aby používal konkrétní index?