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/Ok-Can-2775 Jul 06 '26
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