It may be legitimate in certain pre-calculated fields.
If some of your queries are expensive and you decide to go with pre-calculated fields updated automatically using database triggers, then it may be legitimate to keep the lists inside a column.
For example, in the UI you want to show this list using grid view, where each row can open full details (with complete lists) after double-clicking:
REGISTERED USER LIST +------------------+----------------------------------------------------+ |Name |Top 3 most visited tags | +==================+====================================================+ |Peter |Design, Fitness, Gifts | +------------------+----------------------------------------------------+ |Lucy |Fashion, Gifts, Lifestyle | +------------------+----------------------------------------------------+ You are keeping the second column updated by trigger when client visits new article or by scheduled task.
You can make such a field available even for searching (as normal text).
For such cases, keeping lists is legitimate. You just need to consider case of possibly exceeding maximum field length.
Also, if you are using Microsoft Access, offered multivalued fields are another special use case. They handle your lists in a field automatically.
But you can always fall back to standard normalized form shown in other answers.
Summary: Normal forms of database are theoretical model required for understanding important aspects of data modeling. But of course normalization does not take into account performance or other cost of retrieving the data. It is out of scope of that theoretical model. But storing lists or other pre-calculated (and controlled) duplicates is often required by practical implementation.
In the light of the above, in practical implementation, would we prefer query relying on perfect normal form and running 20 seconds or equivalent query relying on pre-calculated values which takes 0.08 s? No one likes their software product to be accused of slowness.