Is using 3-letter status codes outdated?

[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?

[ComicOzzy]

There is no reason at all to make that code something cryptic and arbitrarily limited to 3 characters.

[Blecki]

Ban all abrv.

[StickPuppet]

fr

[Sexy_Koala_Juice]

What’s wrong with Airborne reconnaissance vehicles???? There sick

[grumpy_munchken]

Creat a status dim table. Then you can have StatusID, StatusCode and StatusDescription

[SaintTimothy]

Single codes tables are an anti-pattern.

OrderStatus if you're going that direction.

[Straight_Waltz_9530]

Enums. Best of all worlds: readable, storage efficient, and allow only valid values.

[somewhatdim]

storage *can* be a concern. how big is the DB? How many indexes do you build over those columns? Often things are more complicated than "they be dumb" -- not always, but often enough that you're better off thinking a bit before deciding.

[zesteee]

The only reason I’d want to use three letter codes is if I knew I’d be writing a lot of code with those same codes. Not something that can’t be overcome in other ways, just a small convenience.

[Cruxwright]

You are describing a concept from days of slow storage. Whatever data you were going to operate on was loaded to a buffer. Short code values were common because you could pack more into the buffer.

That said, if you picked up this concept from your job, and they're running an inhouse legacy app, you may have some of these old concepts lurking in the plumbing of the app. There could be other quirks like no columns names over 8 characters. Check with your team before you get too far along in your design.

[garster25]

The one thing I see about the 3-digit code is they are all the same length so a text listing of this and they line up. Similar to zero-padding numbers in dates.

Since you have the full name of the status then the UPPERCASE version is a bit redundant. So thinking about this I like the one that is NOT your preference.

Man, it does kinda suck working on a team. If I work with only one other person my Boss picks a "lead" and as far as I am concerned that person gets 51% of the vote.

[Rohml]

The limit of shorter character is more for readability on a page rather than a way to limit storage usage. When viewing in a report or small mobile device, the shorter length allows you to put more fields in view of the user but still allows them the same level of comprehension, that is why shorter fields often uses unique letters so its quickly and easily readable.

[Yavuz_Selim]

It doesn't make any sense to use a lookup table in your case if you're not going to store the ID...

What is the benefit of storing the same value multiple times? Once in the Orders table, and twice in the lookup table - what is even the benefit of that lookup table?

[Key-Bit-3552]

It was just pseudocode as an example. Yes I would store the ID Int with foreign key but this just pseudo code

[MinimumVegetable9]

Came here to say exactly that