Should I use Enum type in MySql for Yii2?

Question

MySQL

I use Yii2 and MySql.
I want to add a "technical" type field to the table - the type of record, so that I can interpret the data in different ways (it seems that this practice is not welcome, but for now I want to select all the records I need in one pass through one table, and then display them differently in the form them depending on type).
The Enum type seems attractive, but as I understand it, when you try to add a new record type there, you will have to start changing the entire table.
The alternative is a one-byte tinyint and the creation of named constants in the code so as not to get confused in the numbers. Plus, migrations will remain universal.
Maybe there are some other options?

Answer 1

To solve your problem, you can use:
1. Enum - will make the content of the column more understandable, in contrast to storing data as a number, with approximately the same resource costs. But it should be understood that its use on large amounts of data will indeed lead to decent time costs, if it is necessary to change the list of values. Another question is how often do you plan to do this and how much data will be stored? In addition, you need to understand that in the case of MySQL there is no way to make one common list for several tables. Therefore, if you plan to use it in several tables at once, this will lead to data duplication.
2. Type in the form of a number - will make the contents of the column incomprehensible to third-party developers. For example, a type with a value of 7 will not be able to say anything about its purpose. And sometimes there are tasks that need to be implemented at the base level, and in this case it is extremely inconvenient to look for what 7 is in the code.
3. Type in the form of a separate table - You can put all types in a separate table, and use a link to it in your records. This option will solve some of the problems of the previous ones, but it should be understood that this approach can create a bunch of essentially unused tables in the database, which is also not good.
Those. In fact, each option has its pros and cons. But which one to use - you need to decide in a particular situation, depending on the specifics of the task, choose the most suitable one.

Answer 2

There is also an option to link to another table, with a set of prepared options ... We chose ENUM for ourselves, though not in MySQL, but in PG, but this does not really change the essence of the matter. If you suddenly need to change the table (in PG you will need to change not the table, but the previously created data type) and add a new type, this is done without any problems, because the database and the project have administrators, content managers, and other maintenance personnel.
Why ENUM? We were guided by the fact that it is more readable in the query results and ... In your example - you do not need to change the database, but you need to change the code, in our case - the possibility of creating a record of an unknown type is excluded, including when "manually" changing the database .
In general, in my opinion - the question is more personal preferences, I voiced ours to you :)