This is not a reliable and safe approach. Here some reasons why:
- the same set element could be entered several time in the same field,
- it's difficult to verify that each element in the set is valid,
- you're limited by the maximum value length of the field
- finding rows with a given element is slower, because you need to use a wildcard search, preventing use of indexes and forcing the DBMS to go through all the rows
- if items have variable length searching for item XXX with wildcards might also catch false positive such as item XXXYYY
- order of items in the field is not controlled, so it's difficult to find rows having several specific set elements (because if looking for a row having 3 elements they could be stored in the order A,B,C or C,B,A or B,C,A or C,A,B or B,A,C or B,C,A or A,C,B ro either requiring 6 queries with wildcards around the elements searched, or 3 independent queries and then looking for the rows that appear in the three queries)
- it's very difficult to make more complex queries using the set elements (you can but it's a lot of hand crafted code and unoptimized access).
On the other side, it's an easy, quick and dirty approach, that could be acceptable if the set elements are purely descriptive and are only of marginal use.
The relational way of doing this would be to have a distinct table to represent the set, so for one record having a specific ID as primary key, you would put in the set table, for each of the relevant set elements a new row with the same specific ID and the set element.