Comment by simonask
12 hours ago
English has plenty of Unicode — claiming otherwise is such a cliché…
Unicode is a requirement everywhere human language is used, from Earth to the Boöotes Void.
12 hours ago
English has plenty of Unicode — claiming otherwise is such a cliché…
Unicode is a requirement everywhere human language is used, from Earth to the Boöotes Void.
Just to be pedantic, those characters are in 'ANSI'/CP1252 and would be fine in a varchar on many systems.
Not that I disagree — Win32/C#/Java/etc have 16-bit characters, your entire system is already 'paying the price', so weird to get frugal here.
My comment contains two glyphs that are not in CP1252.
> Unicode is a requirement everywhere human language is used
Strange then how it was not a requirement for many, many years.
It was a mess back then though. Unicode fixed that.
I'm not convinced that Unicode fixed anything. I was kind of hoping, way back when, that everyone would adopt ASCII, as a step to a more united world. But things seem to have got more differentiated, and made things much more difficult.
Also less awkward to make it right the first time, instead of explaining why someone can’t type their name or an emoji
Specifically not talking about a name field
I am talking about coded values, like Status = 'A', 'B' or 'C'
Taking double the space for this stuff is a waste of resources and nobody usually cares about extended characters here in English language systems at least they just want something more readable than integers when querying and debugging the data. End users will see longer descriptions joined from code tables or from app caches which can have unicode.
It's way better to just use a DBMS that supports enums. I know SQL server isn't one of those but I still don't store my coded values as strings.
The way to do enums in SQL (generally, not just MSSQL) is another table. It's better that they don't offer several ways to do the same thing.
1 reply →
How do you store them? Also enums are not user configurable normally. It would be a good feature to have them, but they don't work well in many cases.
Typical code tables with code, description and anything else needed for that value which the user can configure in the app.
Sure you can use integers instead of codes, now all your results look like 1, 2, 3, 4 for all your coded columns when trying to debug or write ad-hoc stuff. Also ints are not variable length so your wasting space for short codes and you have to know ahead time if its only going to be 1,2,4 or 8 bytes.
Those are all single byte characters in UTF-8.
We are talking nvarchar here, yes UTF-8 solves this issue completely and MSSQL supports it now days with varchar.
No. Look closer.
But nvarchar is UTF-16