Вы действительно не должны хранить несколько элементов в одном столбце, если ваш SQL когда-либо захочет обрабатывать их по отдельности. «Гимнастика SQL», которую вы должны выполнять в этих случаях, - это и отвратительные взломы, и снижение производительности.
Идеальное решение состоит в том, чтобы разделить отдельные элементы на отдельные столбцы и, для 3NF, переместить эти столбцы в отдельную таблицу в виде строк, если вы действительно хотите сделать это правильно (но, вероятно, все в порядке с детьми если вы уверены, что в краткосрочной и среднесрочной перспективе не будет более двух причин).
Тогда ваши запросы будут и проще, и быстрее.
Однако, если это не вариант, вы можете использовать вышеупомянутую гимнастику SQL, чтобы сделать что-то вроде:
where find ( ',' |fld| ',', ',02,' ) > 0
при условии, что в вашем диалекте SQL есть функция поиска строки (в данном случае find, но я думаю charindex для SQLServer).
Это обеспечит, чтобы все подколонки начинались и начинались с запятой (запятая плюс поле плюс запятая) и искали определенное желаемое значение (с запятыми с обеих сторон, чтобы обеспечить полное совпадение подколонок).
Если вы не можете контролировать то, что приложение помещает в этот столбец, я бы выбрал решение DBA - решения DBA определяются как решения, которые DBA должен делать, чтобы обойти недостатки своих пользователей : -.)
Создайте два новых столбца в этой таблице и создайте триггер вставки / обновления, который заполнит их двумя причинами, которые пользователь помещает в исходный столбец.
Затем запросите эти два столбца new для конкретных значений, а не пытайтесь разделить старый столбец.
Это означает, что стоимость разделения указана только для вставки / обновления строки, а не для _every single select`, что эффективно амортизирует эту стоимость.
Тем не менее, мой ответ - пересмотреть схему. Это будет лучший способ в долгосрочной перспективе с точки зрения скорости, читабельности запросов и удобства обслуживания.