Using Integer vs String for a "type" value (Database and class design)

Question

I've been developing a few mobile games, in which those games fetch their data from a server-database.

I'm used to storing "type" values as an integer identifier, and an enum in the client to identify the data coming from the server.

As an example: On the database table:

Monsters Table: MonsterId(int), Name(string), MonsterType(int)

On the client-sided code:

typedef enum {
    MonsterTypeGround = 1,
    MonsterTypeAquatic = 2,
    MonsterTypeAmphibious = 3,
    MonsterTypeAerial = 4
}MonsterType;

Note that the above code is Objective-C, in which I can assign integer values. But I'm also using C# and C++.

However, our database guy said that enums are a compiler trick, there’s no such thing as enums data types. He argued that integer type-identifiers make it hard for people(other developers) to understand what the values mean, and that they cannot possibly know the equivalents without looking at the client-sided code and that enums aren't good because you need to make sure the enum syncs with server-side ids and that it's better to use strings instead.

My question is: Is there an objectively correct answer on the matter?

Are there any alternatives aside from using enums on the client-code but will still use integers for the server database?

Answer 1

Long answer

Your database guy is obviously wrong. There, of course, if something like an ENUM data type. You provided one in your example. And MySQL knows of it. And lots of programming languages have something like an ENUM.

But he is also right, in that ENUMs are often (always?) optimized by compilers. If there are four choices that could be represented perfectly by 1 through 4, but we happen to find identifiable strings easier to read in code. But compilers have no such problems and in fact don't care about the number. The Aerial monster is type 4 and the Flying Spaghetti Monster is type 4. It is even easier by an order of several magnitudes for a CPU to compare bytes compared to comparing strings.

Also, he is right that having an ENUM in C code or whatever code can be a problem:

1. If you change the definitions (especially the order), you need to recompile the program and all linked programs if it is a library. That is a pain.
2. If you need to interface with different languages, that can also be a pain. You need to sync multiple definitions.
3. Managing ENUMs is cumbersome, especially removing types.

You can work around this by having a function that translates strings to enums or the other way around.

But there are also benefits:

1. If you change the name of the monster type, any Aerial monster can remain type 4, even if you rename them to Flying monsters. Data consistency in the database is guaranteed, because it is a number. If you use strings, there is no painless way of converting. Well, find and replace will do in code, but not in databases.
2. It is an efficient format. It will save you 10 bytes. My experience is that this rarely matters, except if you have tens of millions of entries.

TL;DR

No there is no objective answer.

If you find programmer ease most important, then strings can be a better option. If you find compiler optimization most important, then an enum is a better option.

My opinion is that compiler optimization is rarely important, but scarce programmer time is. I myself mostly use strings, except in certain databases.

So yes, your guy has a point.