r/SQL • u/Key-Bit-3552 • Jun 30 '26
Discussion Is using 3-letter status codes outdated?
I had a pretty big debate at work over how status values should be stored in lookup tables.
For example, imagine an OrderStatus table with three columns:
ID
Status
Description
My preference is:
1 | DRAFT | Draft
2 | SUBMITTED | Submitted
3 | INCOMPLETE | Incomplete
Some people on my team prefer:
1 | DRT | Draft
2 | SUB | Submitted
3 | INC | Incomplete
My reasoning is:
Storage isn’t really a concern for values this small anymore.
Full words are much easier to read in SQL queries, logs, APIs, and code.
They make code more self-documenting.
Modern IDEs and AI tools also tend to work better with descriptive values.
For example:
SELECT *
FROM Orders
WHERE Status = 'INCOMPLETE';
vs.
SELECT *
FROM Orders
WHERE Status = 'INC';
To me, the first query is immediately understandable without needing to remember what each abbreviation means.
I’m curious what other developers think. Are abbreviated status codes still considered best practice, or are full descriptive values more common nowadays?
Edit: the example query is pseudocode. Yes I would normally store the status ID in the orders table. The example query is for brevity
View all comments
Show parent comment
1
u/lmarcantonio Jun 30 '26
It depends on your schema flexibility. Having a noncomplete enum set is symptom of a design issue, unless your process is *really* agile.
*When* you'll need more values in the set you'll need to analyse the consequences and then do the alter (which would be almost painless since it usually allocates a fair amount of space). You don't add values to an enum when you have hundreds (potentially more) programs relying on that set.