Working on an application - everywhere an enum should be is a database table instead.

Me: What happens when someone changes "rejected" to "approved" in your status table?

Me: What happens when you re-seed your database and the indexes for your types are different?

All problems, with no time or scope to fix!
USE A FUCKING ENUM

Status tables can be necessary if you have other clients that only can use a db query like many report generator applications.

We have that problem where the options are either to use a varchar for the status storing the text in each line, hard code the options in the report query forcing us to rebuild that ti of a new status is added or having a status table.

And if you have clients that need to het reports with statuses in different languages a table makes it easier

Changes from Approved to Rejected would be a change in the status ID, correct?
What's the problem, I don't get it.

As for ID mismatch, how can that be when you're copying data? You're COPYING data, not inventing it.

Let's say there's some simple logic somewhere in your application like:
if(item.status.description == "Approved")
Or
if(item.statusId == 1)

Storing those values in a db where they can be changed means your code no longer works as expected.

Rule of thumb: if you don't want the values changing or adding to at runtime, don't allow them to!

You can't 100% guarantee that database values will always remain the same in the wild - you can guarantee that with enums

@xPunxNotDeadx
There are basically 2 types of tables in a given database, and they are named differently depending on the team you're working in:

Dimension/Fact (actual terms)
Dictionary/Modifiable
Definition/Data
MostlyRead/MostlyWrite
etc.

DB designers will come up with names for them all the time.

The point is that one of them sits still. It's part of the programming, it's a data structure in the database that's essential to everything else. Delete/change 1 row and everything goes to shit.
That's the dimension table.
Rarely written to, always read from.

Those should not be modified by anyone except programmers or system administrators.

The other table - the fact table, are the huge ones, that have lots of columns and rows usually, that describe a thing.

The point is that if you stick to these practices, you can eliminate bugs. Because using enums isn't going to solve the issue that you had described anyway.
Enum says Approved=1. DB says Rejected=1 - Your app is fucked.

That's why I bias toward removing the dimension tables altogether. If the only time the table get written to is when a feature is added, using an enum ensures only programmers can alter the purpose of the values.
If your enum says 1 = Approved, and your DB only stores the int value of the enum, you've protected your application from a user/uneducated admin arbitrarily altering either the description of 1, or the int value of "approved"

From then on, records with statusId 1 can only ever be interpreted by your application as approved, since the textual value of that is fixed, and the logical purpose of 1 remains the same.

I'm not saying there's never a reason to use dimension tables, but if you intend to drive critical logical processes by the ids then an enum with a string value extension does everything you need, while protecting your code from faults beyond your control.

Incidentally, the approved/rejected example was a bad one - use a boolean isApproved for simplicity!

@xPunxNotDeadx the problem with enums is that it forces the usage of a single programming language across all apps that can connect to the DB, and using shared libraries, OR being dependent on a microservice to access the DB, which is a HUGE overhead in terms of performance.

One option is to use code generation tools, that you run before compiling the program, or when restoring packages, whatever. The code generation tool would create enums out of DB data. If you really want enums.

The thing with data dependencies is that they should be accessible from everywhere. Enums are not.

Ah, this is true for solutions where you're allowing applications to connect to the db directly - this is a saas solution, so all clients access data via a controlled WebAPI, which we control.
Using an enum allows you to provide meaning to a status id without the risk of that meaning being changed at runtime.

@xPunxNotDeadx ok...
What if a client wants to add another status?
What if another department wants to analyze software usage and connects to the DB mirror to get the data, and makes their own Enums?
What if someone decides to make some optimizations and run a scheduled job every couple of seconds that does stuff, but for that the best suited platform is, say, Python, for libraries and such, but your software is in Java?

If a user needs to add their own then it's a totally different feature - you're storing more than a key value pair anyway since you need a user (or account) id stored too.
There are no other departments to worry about - we produce and analyse all our own ops intelligence, and we produce the reports for business analysis anyway so that's not a concern.
I don't see why you'd produce recurrent maintenance jobs that require a textual representation of an int anyway, so that's no concern either