"이유 중 하나는 게으름입니다".

모닝콜입니다. 이와 같은 일을 해야 하는 유일한 이유는 "올바른 방법"을 수행하는 방법을 알고 있지만 그렇게 하지 말아야 할 확실한 이유가 있다고 결론을 내리기 때문입니다.

즉, 이 방식으로 저장하기로 선택한 데이터가 쿼리할 필요가 전혀 없는 데이터라면 선택한 방식으로 저장하는 경우가 있을 수 있습니다.

(일부 사용자는 "미래에 어떤 요구 사항이 추가될지 전혀 알 수 없습니다"라고 말하면서 이전 단락의 내 진술에 문제를 제기할 것입니다. 이러한 사용자는 잘못된 정보를 얻었거나 종교적 신념을 진술한 것입니다. 때로는 요구사항이 앞에 있습니다 )

1차 정규형을 위반하는 것 외에도, 반복되는 그룹 값의 열이 쉼표로 구분된 단일 목록에 저장되는 데에는 더 많은 실질적인 문제가 있습니다.

모든 값이 올바른 데이터 유형인지 확인할 수 있는 방법은 없습니다.
• 1,2,3,banana,5를 방지할 수 없습니다.
외래 키 제약 조건을 사용하여 값을 조회 테이블에 연결할 수 없으며 참조 무결성을 적용할 수 없습니다.
고유성을 강제할 수 없음: 차단할 수 없음
• 1,2,3,3,3,5
전체 목록을 가져오지 않으면 목록에서 값을 제거할 수 없습니다.
저장된 목록의 길이는 문자열 열의 길이를 초과할 수 없습니다.
주어진 값을 가진 목록의 모든 항목을 검색하는 것은 어렵습니다. 따라서 비효율적인 테이블 스캔을 사용해야 합니다. 예를 들어 MySQL에서는 정규식을 사용해야 할 수도 있습니다.
• 
  idlist REGEXP '[[:<:>:]]' 或在 MySQL 8.0 中：idlist REGEXP '\b2\b' 李>목록의 요소 개수를 계산하거나 다른 집계 쿼리를 수행하는 것은 어렵습니다.
값이 참조하는 조회 테이블에 값을 연결하는 것은 어렵습니다.
목록을 순서대로 정렬하기가 어렵습니다.
값에 표시되지 않는 것이 보장되는 구분 기호를 선택하기는 어렵습니다

SQL 안티 패턴, 볼륨 1: 데이터베이스 프로그래밍의 함정 피하기.

@OMG Ponies가 언급한 것처럼 이는 예외입니다. 비관계형 "최적화"는 데이터의 다른 사용을 희생하면서 한 유형의 쿼리에 도움이 되므로, 비정규화할 가치가 있도록 특별한 처리가 필요한 쿼리가 무엇인지 확인해야 합니다.