Door: Sherlee Dizon | Bijgewerkt: 2016-06-14 | Reacties (4) | Gerelateerd: 1 | 2 | 3 | Meer > Gegevenstypen
Probleem
De verschillen van SQL Server char, nchar, varchar en nvarchar worden vaak besproken, niet alleen tijdens interviews, maar ook door ontwikkelaars tijdens discussies over databaseontwerp. In deze tip wil ik niet alleen de basisverschillen met u delen,maar ook wat we moeten weten en waar we ons bewust van moeten zijn bij het gebruik van elk datatype.
Oplossing
Char, nchar, varchar en nvarchar worden allemaal gebruikt om tekst of string data op te slaan inSQL Server databases.
- char – is het SQL-92 synoniem voor character. De gegevens worden opgevuld met spaties om de veldgrootte te vullen. Gegevenstype met vaste lengte.
- nchar – is het SQL-92 synoniem voor national char en national character.Gegevenstype met vaste lengte.
- varchar – is het SQL-92 synoniem voor variërend karakter. Gegevenstype met variabele lengte.
- nvarchar – is het SQL-92 synoniem voor nationaal char variërend en nationaalcharacter variërend. Gegevenstype met variabele lengte.
Wat betekent N in SQL Server
Je vraagt je misschien af waar de N voor staat? N staat voorNational Language Character Set en wordt gebruikt om een Unicode string aan te geven. Wanneer Unicode datatypes worden gebruikt, kan in een kolom elk karakter worden opgeslagen dat is gedefinieerd door de Unicode Standard, waaronder alle karakters die zijn gedefinieerd in de verschillende karaktersets. Merk op dat Unicode-datatypen twee keer zoveel opslagruimte innemen als niet-Unicode-datatypen.
Unicode wordt meestal gebruikt in databasetoepassingen die zijn ontworpen om codepagina’s te vergemakkelijken die verder gaan dan de Engelse en West-Europese codepagina’s. Het is zo ontworpen dat uitgebreide tekensets nog steeds in databasekolommen kunnen “passen”. Dit betekent dat Unicode-karakterdatatypes beperkt zijn tot de helft van de ruimte, omdat elke byte in feite twee bytes nodig heeft om de gegevens op te slaan (Unicode wordt soms aangeduid als “dubbelbreed”). SQL Server ondersteunt Unicode sinds SQL Server7.0 door nchar/nvarchar/ntext datatypes te leveren. SQL Server ondersteunt geenUTF-8 encoding voor Unicode data, maar welUTF-16.
Ik heb hieronder een tabel gemaakt die als snelle referentie kan dienen.
Verschillen van char, nchar, varchar en nvarchar in SQL Server
| char | nchar | varchar | nvarchar | Character Data Type | Non-Unicode fixed-length | Unicode fixed-length kan zowel niet-Unicode als Unicode-tekens opslaan (d.w.z.Japanse, Koreaanse, enz.) | Non-Unicode variabele lengte | Unicode variabele lengte kan zowel niet-Unicode als Unicode tekens opslaan (Japans, Koreaans, enz.) | Non-Unicode variabele lengte kan zowel niet-Unicode als Unicode tekens (Japans, Koreaans, enz.)) |
|---|---|---|---|---|---|---|
| Maximale lengte | tot 8.000 tekens | tot 4.000 tekens | tot 8.000 tekens | tot 4,000 tekens | ||
| neemt 1 byte per teken | neemt 2 bytes per Unicode/Niet-Unicode teken | neemt 1 byte per teken | neemt 2 bytes per Unicode/Niet-Unicode teken | neemt 2 bytes per Unicode/Niet-Unicode teken | neemt 1 byte per teken | neemt 2 bytes per Unicode/Niet-Unicode teken |
| Opslaggrootte | n bytes | 2 keer n bytes | Eigenlijke lengte (in bytes) | 2 keer werkelijke lengte (in bytes) | ||
| Gebruik | gebruiken bij constante gegevenslengte of kolommen met een vaste lengte | alleen gebruiken als Unicode-ondersteuning nodig is, zoals de Japanse Kanji- of Koreaanse Hangul-tekens, vanwege de opslagoverhead | gebruikt als de gegevenslengte variabel is of kolommen met variabele lengte en als de feitelijke gegevens altijd veel minder zijn dan de capaciteit | alleen gebruiken als u Unicode-ondersteuning nodig hebt, zoals de Japanse Kanji- of KoreaanseHangul-tekens, vanwege de opslagoverhead | ||
| query die gebruikmaakt van een varchar-parameter een index zoekt vanwege kolomcollatiesets | query die een nvarchar-parameter gebruikt, een indexscan uitvoert vanwege kolomcollatiesets |
Voordelen en nadelen van char, nchar, varchar en nvarchar in SQLServer
| Datatatypes | Voordelen | Voordelen |
|---|---|---|
| char | De query performance is beter omdat de kolom niet verplaatst hoeft te worden tijdens het updaten. Het is niet nodig om de lengte van de string in de laatste twee bytes op te slaan. |
Als het niet goed wordt gebruikt, kan het meer ruimte innemen dan varchar, omdat het een vaste lengte heeft en we de lengte van de string niet kennen. Het is niet goed voor compressie omdat het spaties aan het eind bevat. |
| varchar | Doordat het een variabele lengte heeft, neemt het minder geheugenruimte in beslag. | Vermindert de prestaties van sommige SQL-query’s. |
| nchar/nvarchar | Ondersteunt veel client computers die verschillende locales draaien. | Als het niet goed wordt gebruikt kan het veel extra opslagruimte in beslag nemen. |
Met de groei en innovatie van web applicaties is het nog belangrijker geworden om client computers te ondersteunen die verschillende locales draaien. De eenvoudigste manier om tekengegevens in internationale databases te beheren is om altijd de Unicodenchar-, nvarchar- en ntext-gegevenstypen te gebruiken, in plaats van hun niet-Unicode-equivalenten char, varchar en text.
Unicode is een standaard voor het omzetten van codepunten in tekens. Omdat het is ontworpen om alle tekens van alle talen van de wereld te dekken, is er geen noodzaak voor verschillende code pagina’s om verschillende sets van tekens te behandelen. SQL Server ondersteunt de Unicode standaard, versie 3.2. Indien alle toepassingen die werken met internationale databases ook gebruik maken van Unicode variabelen in plaats van niet-Unicode variabelen, behoeven er nergens in het systeem tekenomzettingen te worden uitgevoerd. Cliënten zullen dezelfde tekens in de gegevens zien als alle andere cliënten.
SQL Server slaat alle tekstuele systeemcatalogusgegevens op in kolommen met Unicode datatypes. De namen van databaseobjecten, zoals tabellen, views en stored procedures, worden in Unicode-kolommen opgeslagen. Hierdoor kunnen toepassingen worden ontwikkeld door alleen Unicode te gebruiken, en kunnen problemen met conversies van codepagina’s worden voorkomen.
Bedenk bij het ontwikkelen van nieuwe toepassingen of deze wereldwijd zullen worden gebruikt, omdat u aan de hand daarvan kunt bepalen of u nchar en nvarchar moet gebruiken om verschillende talen te ondersteunen.
Volgende stappen
Lees meer door het volgende te lezen en te onderzoeken:
- Neem ook de tijd om deze tip te lezen die u kan helpen bij het plannen van uw databasedesignDefining Data Types and Sizes
- Lees meer over het belang van datatype consistentieSQL Server Data Type Consistency
- Vergelijk SQL Server en Oracle datatypes
- Als u een applicatie heeft die u globaal wilt gaan gebruiken, probeer dan eens te verkennen metglobal characters. Wie weet als je succes hebt verhoog je je omzet en breng je je apps naar het volgende niveau.
Laatst bijgewerkt: 2016-06-14
Over de auteur
Sherlee Dizon is een IT consultant en web applicatie ontwikkelaar met meer dan 14 jaar ervaring als software en web ontwikkelaar.Bekijk al mijn tips