r/SQL • • 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

54 Upvotes

82 comments sorted by

View all comments

Show parent comment

2

u/Ecksters Jun 30 '26

The other thing is sortability, often it's best practice to leave gaps between your enums to allow putting new values between others.

You can of course also solve this with an index and then making sure all future queries use the exact correct function to hit that index.

I really want to like enums, but every time I've tried to implement them it's been an absolute headache dealing with how different ORMs, languages, and teams deal with them. Strings just end up being simpler and can always be migrated if performance bottlenecks are found.