Recently, I started to work on some legacy system. People that developed it, came to an idea to store list of strings in single field of database table. Lets say that it is an identifier for object that does not have any representation nor data in database. The range of that identifiers will be relatively small in production.
On the other hand, my intuitions and "good design taste" tells me that it should be represented in separate table (similar to a table used for representing many-to-many relations).
Is their approach really bad and it would be better to start a refactoring? If yes, what bad consequences the original design can cause in future? Are there any relational design principles that explain that approach?
Edit to response for comments:
As I suppose, they didn't use this approach to solve some specific problem like hierarchical structuring in a tricky way. The most probable scenario was the case that they were simply working under time pressure and needed to implement new features as quick as possible.
I am sure that previously the field represented single value. They were going to implement feature to store more then one value and tried to avoid database migrations.