Does it make sense to use look-up table with only 1 column?

So consequently in that case, is it better to look for natural or surrogate keys?

You need to tell us more about you problem domain if you expect an answer…

It’s very generic question. Let say I have a table with unique values, say tags or zip code. I know that this approach would be useful in case when one has to store additional data. But let’s assume for a moment that it’s a 1 column table.

Your examples are not what a developer would call a “look-up table” and I wouldn’t use a one column table for you examples since that comes with a cost. For example the tags: They will be usually longer than a numeric value suitable for the number of tags you want to be able to handle. You have to store the whole tag each time you want to tag an entity. That’s costly in terms of memory and storage. If you want to change a tag e.g. because you mispelled the tag “JavaScript” as “JavaScirpt” you have to change all the tagged entities also. That’s costly in terms of db load.

Often a surrogate key (db generated, AUTO_INCREMENT) is a good option.

Sounds reasonable. Thank you for the explanation.