V současné době v naší databázi SQL Server 2012 používáme varchar
a chtěli bychom to změnit nvarchar
. Vytvořil jsem skript, abych to udělal.
Moje otázka je, existují nějaké rozdíly v tom, jak SQL Server zapisuje do sloupců varchar
oproti sloupcům nvarchar
? Máme řadu backend procedur, které mě znepokojují.
Upravit:
Nejste si jisti, zda to pomůže, ale sloupce na nich nemají indexy, f/k nebo omezení.
Musíte si být jisti, že předponu řetězce Unicode předepisujete předponou N. Například tyto budou fungovat odlišně, pokud je základní datový typ NVARCHAR
:
CREATE TABLE dbo.t(c NVARCHAR(32));
INSERT dbo.t(c) SELECT 'រៀន';
INSERT dbo.t(c) SELECT 'នរៀ';
INSERT dbo.t(c) SELECT N'រៀន';
SELECT c FROM dbo.t;
SELECT c FROM dbo.t WHERE c = 'រៀន';
SELECT c FROM dbo.t WHERE c = N'រៀន';
Výsledek:
c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!
c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?
c
----
រៀន
Pro ty, kteří používají mobilní zařízení nebo dešifrované prohlížeče, které zobrazují znaky pole namísto skutečných znaků Unicode, vypadá to takto:
Největší obava je, že nvarchar
používá 2 bajty na znak, zatímco varchar
používá 1. Takže nvarchar(4000)
používá stejné množství úložného prostoru jako varchar(8000)
*.
Kromě všech údajů o vaší postavě, které vyžadují dvojnásobek úložného prostoru, to také znamená:
nvarchar
, abyste udrželi řádky v mezích sloupce 8060 bajtů/8000 bajtů.nvarchar(max)
, budou vypnuty mimo řádek dříve, než by to udělal varchar(max)
.nvarchar
, abyste zůstali v limitu 900bajtového indexového klíče (nevím, proč byste chtěli použít tak velký indexový klíč, ale nikdy nevíte).Kromě toho, práce s nvarchar
není moc odlišná, za předpokladu, že váš klientský software je vytvořen pro práci s Unicode. SQL Server bude transparentně převádět varchar
na nvarchar
, takže pro řetězcové literály nepotřebujete striktně předponu N, pokud v literálu nepoužíváte 2bajtové (tj. Unicode) znaky. Uvědomte si, že obsazení nvarchar
to varbinary
přináší jiné výsledky než dělat to samé s varchar
. Důležité je, že nemusíte okamžitě měnit každý literál varchar za literál nvarchar, aby aplikace zůstala funkční, což usnadňuje proces.
* Pokud používáte kompresi dat (dostatečná komprimace řádků je dostatečná, vyžaduje Enterprise Edition před SQL Server 2016 SP1 ), obvykle najdete nchar
a nvarchar
nezabere více místa než char
a varchar
, díky komprese Unicode (pomocí algoritmu SCSU) .
Považujte za hlavní rozdíly následující:
nvarchar byl vyžadován pro RDP Merge Replication z Mobile DB na SQL Server 2005. Také LTrim (), RTrim () & Trim () byly použity hodně bc nvarchar nebyl automaticky oříznut () mezery od zadávání dat, zatímco Varchar ano .
Nejsem si vědom, zda se to v posledních letech změnilo nebo ne, ale nvarchar je nyní standardem používaným pro přihlášení .NET Simple Membership Website na serveru VS Pro 2017, který se používá ve vygenerované databázi.