Tuesday 15 April 2014

Picking the right SQL Server collation for storage -


How does the SQL Server implement the collation in the case of storage and how it affects Unicode and non-Unicode data types?

  • Is the effect of signaling Unicode storage? Or just control the sorting rules within the database?

  • When I use non-Unicode data types, is the signaling connected to the bond?

  • What happens if restrictions are applied, when I try to store a letter in a non-Unicode data type database matching?

I understand that the Unicode data type can always store a full set of Unicode data, whereas the storage capabilities of the non-Unicode data type depend on the page (which Collation) and can only represent many common characters in that match.

Clearly, each letter will occupy at least 2 bytes in a Unicode data type, while the non-Unicode data types occupy 1 byte per character (or is it how the collation Is there a difference?)

Set me up here, how does this really work?

"post-text" itemprop = "text">

SQL Server stores Unicode data (NTEXT, NVARCHAR) in UCS2, always generates 2 bytes per character.

A matching affects only sorting (and wrapper).

In non-Unicode data types (text, VARCHAR) only one byte per character is used, and only the letters of the code page of the call will be stored (as you said). See it


No comments:

Post a Comment