I modsætning til nogle andre RDBMS'er, der giver mulighed for at vælge en kodning, gemmer SQL Server kun Unicode-data i UTF-16 (Little Endian) og ikke-Unicode-data i en 8-bit-kodning (Extended ASCII, DBCS eller EBCDIC) uanset hvilken kodeside, der antydes af feltets sortering.
Deres beslutning om at vælge UCS-2 giver mening nok, da UTF-16 blev introduceret i midten af 1996 og fuldt ud specificeret i 2000. Mange andre systemer bruger (eller brugte) det også (se venligst:https://en.wikipedia.org/wiki/UTF-16#Usage ). Deres beslutning om at fortsætte med det kan være mere tvivlsomt, selvom det sandsynligvis skyldes, at Windows og .NET er UTF-16. Det fysiske layout af bytes er det samme mellem UCS-2 og UTF-16, så opgradering af systemer fra UCS-2 til at understøtte UTF-16 bør være rent funktionelt uden behov for at ændre eksisterende data.
Øh nej. Oprettelse af en brugerdefineret brugerdefineret type via SQLCLR er ikke , på nogen måde, vil give dig en erstatning af enhver indfødt type. Det er meget praktisk til at skabe noget til at håndtere specialiserede data. Men strenge, selv af en anden kodning, er langt fra specialiserede. At gå denne vej for dine strengdata ville ødelægge enhver mængde anvendelighed af dit system, for ikke at nævne ydeevne, da du ikke ville være i stand til at bruge nogle indbyggede strengfunktioner. Hvis du var i stand til at spare noget på diskplads, ville disse gevinster blive slettet af, hvad du ville miste i den samlede ydeevne. Lagring af en UDT sker ved at serialisere den til en VARBINARY . Så for at gøre hvilket som helst strengsammenligning ELLER sortering, uden for en "binær" / "ordinær" sammenligning, skal du konvertere alle andre værdier, én efter én, tilbage til UTF-8 for derefter at udføre strengsammenligningen, der kan tage højde for sproglige forskelle.
Også, at "dokumentation" er egentlig bare prøvekode / proof of concept ting. Koden blev skrevet i 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) til SQL Server 2005. Jeg så et script til at teste funktionalitet, men intet, der involverer ydeevne.
Ja, i høj grad. Som standard er håndteringen af de indbyggede funktioner kun for UCS-2. Men fra og med SQL Server 2012 kan du få dem til at håndtere det fulde UTF-16-tegnsæt (godt, fra Unicode Version 5 eller 6, afhængigt af dit OS og version af .NET Framework) ved at bruge en af de sorteringer, der har et navn, der ender på _SC (dvs. supplerende tegn).
Korrekt. UTF-16 og UCS-2 bruger begge 2-byte kodepunkter. Men UTF-16 bruger nogle af dem i par (dvs. surrogatpar) til at kortlægge yderligere karakterer. Kodepunkterne, der bruges til disse par, er reserveret til dette formål i UCS-2 og bruges derfor ikke til at tilknytte nogen brugbare symboler. Det er derfor, du kan gemme ethvert Unicode-tegn i SQL Server, og det vil blive gemt og hentet korrekt.
Korrekt, men vildledende. Ja, UTF-8 er variabel bredde, men UTF-16 er også mindre variabel, da alle de supplerende tegn er sammensat af to dobbeltbyte kodepunkter. Derfor bruger UTF-16 enten 2 eller 4 bytes pr. symbol, selvom UCS-2 altid er 2 bytes. Men det er ikke den vildledende del. Det, der er vildledende, er implikationen, at enhver anden Unicode-kodning ikke er i stand til at kode alle andre kodepunkter. Mens UCS-2 kan holde dem, men ikke fortolke dem, kan både UTF-16 og UTF-32 begge kortlægge alle Unicode-kodepunkter, ligesom UTF-8.
Det kan være rigtigt, men det er fuldstændig irrelevant fra et operationelt perspektiv.
Igen, sandt, men fuldstændig irrelevant, da UTF-16 og UTF-32 også kortlægger alle Unicode-kodepunkter.
Afhængigt af omstændighederne kan dette meget vel være sandt, og du er med rette bekymret over sådan spild brug. Men som jeg nævnte i spørgsmålet, der førte til dette ( UTF-8 Support, SQL Server 2012 og UTF8String UDT
), har du et par muligheder for at mindske mængden af spildplads, hvis de fleste rækker kan passe ind i VARCHAR alligevel skal nogle være NVARCHAR . Den bedste mulighed er at aktivere RÆKKEKOMPRESSION eller SIDEKOMPRESSION (kun Enterprise Editon!). Fra og med SQL Server 2008 R2 tillader de ikke-MAX NVARCHAR felter for at bruge "Standard Compression Scheme for Unicode", som er mindst lige så god som UTF-8, og i nogle tilfælde er det endda bedre end UTF-8. NVARCHAR(MAX) felter kan ikke bruge denne smarte komprimering , men deres IN ROW-data kan drage fordel af almindelig ROW- og/eller PAGE-komprimering. Se venligst følgende for en beskrivelse af denne komprimering og et diagram, der sammenligner datastørrelser for:rå UCS-2 / UTF-16, UTF-8 og UCS-2 / UTF-16 med datakomprimering aktiveret.
SQL Server 2008 R2 - UCS2-komprimering hvad er det - Indvirkning på SAP-systemer
Se venligst også MSDN-siden for Datakomprimering for flere detaljer, da der er nogle begrænsninger (udover at den kun er tilgængelig i Enterprise Edition -- MEN gjort tilgængelig for alle udgaver, der starter med SQL Server 2016, SP1 !!) og nogle omstændigheder, hvor komprimering kan gøre tingene værre.
Sandheden af denne erklæring afhænger af, hvordan man definerer "disk". Hvis du taler om råvaredele, som du kan købe fra hylden i en butik til brug i din stationære / bærbare computer, så sikker. Men hvis vi taler om lagerplads på virksomhedsniveau, der vil blive brugt til dine produktionssystemer, så hav det sjovt med at forklare den, der kontrollerer budgettet, at de ikke skal afvise det million-plus-dollar SAN, som du ønsker, fordi det er "billigt". ";-).
Ingen jeg kan komme i tanke om. Nå, så længe du ikke følger nogen forfærdelige råd om at gøre noget som at implementere den UDT eller konvertere alle strengene til VARBINARY , eller ved at bruge NVARCHAR(MAX) for alle strengfelter;-). Men af alle de ting, du kunne bekymre dig om, burde SQL Server, der bruger UCS-2 / UTF-16, ikke være en af dem.
Men hvis dette problem af en eller anden grund med manglende indbygget understøttelse af UTF-8 er super vigtigt, så skal du muligvis finde et andet RDBMS at bruge, der tillader UTF-8.
OPDATERING 2018-10-02
Selvom dette ikke er en levedygtig mulighed endnu, introducerer SQL Server 2019 indbygget understøttelse af UTF-8 i VARCHAR / CHAR datatyper. Der er i øjeblikket for mange fejl med det til at det kan bruges, men hvis de er rettet, så er dette en mulighed for nogle scenarier. Se venligst mit indlæg, "Native UTF-8-understøttelse i SQL Server 2019:Frelser eller falsk profet?
", for en detaljeret analyse af denne nye funktion.