4 ms·
Mostly agree with the author but hadn't thought terribly deeply about it in the past. The N/`CHAR` data type has served as somewhat of a code smell. I use the
by mdip 3y ago
Mostly agree with the author but hadn't thought terribly deeply about it in the past.
The N/`CHAR` data type has served as somewhat of a code smell. I use the following approach when deciding (against) selecting fixed-width char types:
((1)) Is it ALWAYS a single character? Yes: use N/CHAR(1) No ... ((2)) Is it ALWAYS fixed width? No, use VARCHAR. ((3)) Is there a more appropriate type to use for the fixed-width data.
The third item tends to be the killer of CHAR(x>1). Too often the underlying data was converted to a fixed width string and stored that way when it should have been stored using a different type. I've seen everything from GUIDs-as-text which could be UNIQUEIDENTIFIERs to CSS hex codes that could be stored as integer values.*
- jeltz 3y agoWhat is the point of ever using CHAR(n) even when it is just a single character? See the example below for how it can be confusing if someone for some reason ever decides to try to put a space into the field. Nah, simply just never use CHAR(n). Instead use varachar/nvarchar/text depending on your database or enum/uuid/... if it should not be a string. The CHAR(n) only exists for standard compliance and should in my opinion really be removed from the SQL standard. # SELECT ' '::char(1) = ''; ?column? ---------- t (1 row)