3 ms·

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

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.

NegativeLatency 7mo ago
Also less awkward to make it right the first time, instead of explaining why someone can’t type their name or an emoji
- SigmundA 7mo ago
  Specifically not talking about a name field
SigmundA 7mo ago
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.
- kstrauser 7mo ago
  Those are all single byte characters in UTF-8.
  - simonask 7mo ago
    No. Look closer.
  - croes 7mo ago
    But nvarchar is UTF-16
  - SigmundA 7mo ago
    We are talking nvarchar here, yes UTF-8 solves this issue completely and MSSQL supports it now days with varchar.
- deleted 7mo ago
  [deleted]
- wvenable 7mo ago
  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.
  - andy81 7mo ago
    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.
    - SigmundA 7mo ago
      Mostly agree separate tables can have multiple attributes besides a text description and can be exposed for modification to the application easily so users or administrators can add and modify codes. A common extra attribute for a coded value is something for deprecation / soft delete, so that it can be marked as no longer valid for future data but existing data can remain with that code, also date ranges its valid for etc, also parent child code relationships. Enums would be a good feature but they have a much more limited use case for static values you know ahead of time that will have no other attributes and values cannot be removed even if never used or old data migrated to new values. Common real world codes like US postal state can take advantage of there being agreed upon codes such as 'NY' and 'New York'.
    - sgarland 7mo ago
      While I generally would prefer lookup tables, it's much easier to sell dev teams on "it looks and acts like a string - you don't have to change anything."
  - SigmundA 7mo ago
    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.
Slothrop99 7mo ago
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.
- simonask 7mo ago
  My comment contains two glyphs that are not in CP1252.
zabzonk 7mo ago
> Unicode is a requirement everywhere human language is used Strange then how it was not a requirement for many, many years.
- procaryote 7mo ago
  It was a mess back then though. Unicode fixed that.
  - zabzonk 7mo ago
    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.
    - simonask 7mo ago
      For whom? Certainly not any of the humans trying to use the computer.
    - procaryote 7mo ago
      The options were never ASCII or unicode though. Before unicode we had ASCII + lots of different incompatible encodings that relied on metadata to be properly rendered. That's what unicode fixed Besides I like being able to put things like →, €, ∞ or ∆ into text. With ascii a lot of things that are nowadays trivial would need markup languages
- Macha 7mo ago
  Oh, it was. It was fun being unable to type a euro sign or the name Seán without it being garbled. Neither were matched quotation marks, and arguably computer limitations killed off naïve and café too. Don’t confuse people groaning and putting up with limitations as justifying those limitations.
- pjmlp 7mo ago
  In Portugal it always was, that is why we got to use eh for é, ah for á, he for è, c, for ç and many other tricks. Shared by other European languages, like ou for ö in German, kalimera for καλημέρα, and so on all around the world in non-English speaking countries during the early days of computing.

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.

NegativeLatency 7mo ago

Also less awkward to make it right the first time, instead of explaining why someone can’t type their name or an emoji

SigmundA 7mo ago
Specifically not talking about a name field

SigmundA 7mo ago

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.

kstrauser 7mo ago
Those are all single byte characters in UTF-8.
- simonask 7mo ago
  No. Look closer.
- croes 7mo ago
  But nvarchar is UTF-16
- SigmundA 7mo ago
  We are talking nvarchar here, yes UTF-8 solves this issue completely and MSSQL supports it now days with varchar.
deleted 7mo ago
[deleted]
wvenable 7mo ago
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.
- andy81 7mo ago
  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.
  - SigmundA 7mo ago
    Mostly agree separate tables can have multiple attributes besides a text description and can be exposed for modification to the application easily so users or administrators can add and modify codes. A common extra attribute for a coded value is something for deprecation / soft delete, so that it can be marked as no longer valid for future data but existing data can remain with that code, also date ranges its valid for etc, also parent child code relationships. Enums would be a good feature but they have a much more limited use case for static values you know ahead of time that will have no other attributes and values cannot be removed even if never used or old data migrated to new values. Common real world codes like US postal state can take advantage of there being agreed upon codes such as 'NY' and 'New York'.
  - sgarland 7mo ago
    While I generally would prefer lookup tables, it's much easier to sell dev teams on "it looks and acts like a string - you don't have to change anything."
- SigmundA 7mo ago
  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.

Slothrop99 7mo ago

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.

simonask 7mo ago
My comment contains two glyphs that are not in CP1252.

zabzonk 7mo ago

> Unicode is a requirement everywhere human language is used Strange then how it was not a requirement for many, many years.

procaryote 7mo ago
It was a mess back then though. Unicode fixed that.
- zabzonk 7mo ago
  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.
  - simonask 7mo ago
    For whom? Certainly not any of the humans trying to use the computer.
  - procaryote 7mo ago
    The options were never ASCII or unicode though. Before unicode we had ASCII + lots of different incompatible encodings that relied on metadata to be properly rendered. That's what unicode fixed Besides I like being able to put things like →, €, ∞ or ∆ into text. With ascii a lot of things that are nowadays trivial would need markup languages
Macha 7mo ago
Oh, it was. It was fun being unable to type a euro sign or the name Seán without it being garbled. Neither were matched quotation marks, and arguably computer limitations killed off naïve and café too. Don’t confuse people groaning and putting up with limitations as justifying those limitations.
pjmlp 7mo ago
In Portugal it always was, that is why we got to use eh for é, ah for á, he for è, c, for ç and many other tricks. Shared by other European languages, like ou for ö in German, kalimera for καλημέρα, and so on all around the world in non-English speaking countries during the early days of computing.