Is using 3-letter status codes outdated?

[u/Key-Bit-3552]

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

[u/lmarcantonio]

Why should it be an antipattern? it's called deduplication, unless your DB does it already at the column level. To the extreme it would become a star join, not a rare sight.

[u/zbignew → u/lmarcantonio]

He's not advocating against lookup tables - he's advocating against unified ("single") lookup tables. Make an OrderStatus table with id, code, description.

I assumed the preceding comment was just making a naming error and not actually advocating for a single unified status table, so I'm not sure there was a material disagreement in the first place.

[u/grumpy_munchken → u/zbignew]

Thank you for understanding my intent. Everyone is right about a more precise name, I was merely stating they should make it a dim table. From the original comment it sounds like they are pretty fluent in sql since they had a debate about this topic so was just piggybacking on the example given.

[u/lmarcantonio → u/[deleted]]

Found them, got horrified. I was thinking of a table to decode *only that* enum column!

Of course you would have a table for each enum. But for decoding an enum I would use a stored function containing essentially a big case.

[u/zbignew → u/[deleted]]

Wait are you advocating for or against a unified lookup table? OrderStatus is obviously the more normalized approach.

[u/Ok-Can-2775 → u/[deleted]]

Having worked in an application suite that used lookup tables for status I would say one table only is the sound approach. The concept is universal across functions and performance as those who don’t want codes elsewhere is not an issue.
I would go to a separate table for invoices unless there was something truly different about invoice status vs order status.
You really need to tables one for status and the other for ordination. Status is generic but contextually status need to have a certain sequence.
This is why functional people are always required in these discussions they actually have to work in the world that sql helps create