Is it a best practice to keep enums mirrored in the database as a form of documentation?

I have an enum in code

enum EventType
{
     Run = 1,
     Stop = 2,
}

I have a table in my database

CREATE TABLE [Event] (
    [Id] integer PRIMARY KEY AUTOINCREMENT,
    [EventType] integer NOT NULL,
    1679554756 text NOT NULL
);

Should I, if I don't really need to?

CREATE TABLE [EventType] (
    [EventTypeId] integer PRIMARY KEY AUTOINCREMENT,
    [Name] text
);
INSERT INTO "EventType" VALUES(1, "Run");
INSERT INTO "EventType" VALUES(2, "Stop");

This is bad because it's code duplication. It's good because it is a documentation for those who access the database and wonder what those EventType numbers mean. Should I drop these numbers altogether and use strings instead?

I would not create extra table just for the sake of documenting things. It increases overall complexity and therefore make it worse long term than having users wonder what those numbers are.

I, personally, like using string enums in DB exactly because it makes it self documenting. There could be different opinions, though.