Till skillnad från vissa andra RDBMS som gör det möjligt att välja en kodning, lagrar SQL Server endast Unicode-data i UTF-16 (Little Endian), och icke-Unicode-data i en 8-bitars kodning (Extended ASCII, DBCS eller EBCDIC) för vilken kodsida som helst som antyds av fältets sortering.
Deras beslut att välja UCS-2 är vettigt nog med tanke på att UTF-16 introducerades i mitten av 1996 och helt specificerade år 2000. Många andra system använder (eller använde) det också (se:https://en.wikipedia.org/wiki/UTF-16#Usage ). Deras beslut att fortsätta med det kan vara mer tveksamt, även om det förmodligen beror på att Windows och .NET är UTF-16. Den fysiska layouten för bytes är densamma mellan UCS-2 och UTF-16, så att uppgradera system från UCS-2 för att stödja UTF-16 bör vara rent funktionellt utan att behöva ändra några befintliga data.
Öh nej. Att skapa en anpassad användardefinierad typ via SQLCLR är inte , på vilket sätt som helst, kommer att ge dig en ersättning av vilken typ som helst. Det är väldigt praktiskt för att skapa något för att hantera specialiserad data. Men strängar, även av en annan kodning, är långt ifrån specialiserade. Att gå den här vägen för dina strängdata skulle förstöra all användbarhet av ditt system, för att inte tala om prestanda eftersom du inte skulle kunna använda någon inbyggda strängfunktioner. Om du kunde spara vad som helst på diskutrymme, skulle dessa vinster raderas av vad du skulle förlora i total prestanda. Att lagra en UDT görs genom att serialisera den till en VARBINARY . Så för att göra vilket som helst strängjämförelse ELLER sortering, utanför en "binär" / "ordinär" jämförelse, skulle du behöva konvertera alla andra värden, ett efter ett, tillbaka till UTF-8 för att sedan göra strängjämförelsen som kan ta hänsyn till språkliga skillnader.
Dessutom är den "dokumentationen" egentligen bara exempelkod / proof of concept-grejer. Koden skrevs 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) för SQL Server 2005. Jag såg ett skript för att testa funktionalitet, men inget som involverade prestanda.
Ja, verkligen. Som standard är hanteringen av de inbyggda funktionerna endast för UCS-2. Men från och med SQL Server 2012 kan du få dem att hantera hela UTF-16-teckenuppsättningen (tja, från och med Unicode version 5 eller 6, beroende på ditt operativsystem och version av .NET Framework) genom att använda en av de sammanställningar som har ett namn som slutar på _SC (dvs tilläggstecken).
Korrekt. UTF-16 och UCS-2 använder båda 2-byte kodpunkter. Men UTF-16 använder några av dem i par (dvs surrogatpar) för att mappa ytterligare tecken. Kodpunkterna som används för dessa par är reserverade för detta ändamål i UCS-2 och används därför inte för att mappa till några användbara symboler. Det är därför du kan lagra vilket Unicode-tecken som helst i SQL Server och det kommer att lagras och hämtas korrekt.
Rätt, även om det är missvisande. Ja, UTF-8 har variabel bredd, men UTF-16 är också lite variabel eftersom alla tilläggstecken är sammansatta av två dubbelbyte-kodpunkter. Därför använder UTF-16 antingen 2 eller 4 byte per symbol, även om UCS-2 alltid är 2 byte. Men det är inte den missvisande delen. Det som är missvisande är implikationen att någon annan Unicode-kodning inte är kapabel att koda alla andra kodpunkter. Medan UCS-2 kan hålla dem men inte tolka dem, kan både UTF-16 och UTF-32 båda mappa alla Unicode-kodpunkter, precis som UTF-8.
Detta kan vara sant, men det är helt irrelevant ur ett operativt perspektiv.
Återigen, sant, men helt irrelevant eftersom UTF-16 och UTF-32 också mappar alla Unicode-kodpunkter.
Beroende på omständigheterna kan detta mycket väl vara sant, och du är rätt i att vara orolig över sådan slösaktig användning. Men som jag nämnde i frågan som ledde till denna ( UTF-8 Support, SQL Server 2012 och UTF8String UDT
), har du några alternativ för att minska mängden utrymme som går till spillo om de flesta rader får plats i VARCHAR men vissa måste vara NVARCHAR . Det bästa alternativet är att aktivera RADKOMPRESSION eller SIDKOMPRESSION (endast Enterprise Editon!). Från och med SQL Server 2008 R2 tillåter de icke-MAX NVARCHAR fält för att använda "Standard Compression Scheme for Unicode" som är minst lika bra som UTF-8, och i vissa fall är det till och med bättre än UTF-8. NVARCHAR(MAX) fields kan inte använda denna snygga komprimering , men deras IN ROW-data kan dra nytta av vanlig ROW- och/eller PAGE-komprimering. Se följande för en beskrivning av denna komprimering och ett diagram som jämför datastorlekar för:rå UCS-2 / UTF-16, UTF-8 och UCS-2 / UTF-16 med datakomprimering aktiverad.
SQL Server 2008 R2 - UCS2-komprimering vad är det - Inverkan på SAP-system
Se även MSDN-sidan för Datakomprimering för mer information eftersom det finns vissa begränsningar (utöver att det bara är tillgängligt i Enterprise Edition -- MEN görs tillgängligt för alla utgåvor som börjar med SQL Server 2016, SP1 !!) och vissa omständigheter då komprimering kan göra saken värre.
Sannheten i det påståendet beror på hur man definierar "disk". Om du talar om råvarudelar som du kan köpa från hyllan i en butik för användning i din stationära/bärbara dator, så säker. Men om vi pratar om lagring på företagsnivå som kommer att användas för dina produktionssystem, ha kul med att förklara för den som kontrollerar budgeten att de inte ska avvisa det miljontals-plus-dollar SAN som du vill ha eftersom det är "billigt ";-).
Inget jag kan komma på. Tja, så länge du inte följer några hemska råd att göra något som att implementera den UDT eller konvertera alla strängarna till VARBINARY , eller med NVARCHAR(MAX) för alla strängfält;-). Men av alla de saker du kan oroa dig för bör SQL Server som använder UCS-2 / UTF-16 inte vara en av dem.
Men om det här problemet med att inget inbyggt stöd för UTF-8 av någon anledning är superviktigt, kan du behöva hitta ett annat RDBMS att använda som tillåter UTF-8.
UPPDATERING 2018-10-02
Även om detta inte är ett genomförbart alternativ än, introducerar SQL Server 2019 inbyggt stöd för UTF-8 i VARCHAR / CHAR datatyper. Det finns för närvarande för många buggar med den för att den ska kunna användas, men om de är åtgärdade är detta ett alternativ för vissa scenarier. Se mitt inlägg, "Native UTF-8-stöd i SQL Server 2019:Frälsare eller False Prophet?
", för en detaljerad analys av denna nya funktion.