컴퓨터 프로그램은 프로그래머가 의도한 대로 동작한다.
같은 목적의 프로그램이더라도 효율적으로 동작하는것이 더 좋은 프로그램이 된다.
컴퓨터 알고리즘에서는 이를 평가하기 위해, 시간 복잡도와 공간 복잡도를 사용한다.
같은 이유로 데이터베이스에서도 '더 작은 공간을 사용'하고, '더 빠르게 처리할 수 있도록' 하며, 이를 위해 데이터 자료형을 사용하게 되었다.
텍스트 데이터를 어떤 방식으로 인코딩하여 저장할 것인가를 결정하는 값
한글 인코딩을 위해 가장 널리 사용되는 방식 : utf-8, EUC-KR
-> 한글자당 3bytes를 사용하는 utf-8보다, 4bytes를 사용하면서 이모티콘까지 표현 가능한 utf8mb4를 더 많이 사용하는 추세.
웹 프로그램과 데이터베이스가 문자를 주고 받을때에는 charset만 설정하면 된다.
"내가 보낼 문자열은 utf8입니다"라고 알려주며, text stream을 전송하면 알맞게 처리한다.
둘 다 한글이 깨지지않게 인코딩해주지만 차이가있다.
문자, 동영상, 음악과 같은 사람이 현실에서 사용하는 데이터를 컴퓨터에 저장하기 위해 컴퓨터가 이해할 수 있는 데이터로 변환하는 작업
이 문제를 해결하기 위해 '유니코드' 개발
Character set에 의해 저장된 데이터들이 어떤 방식으로 정렬될지 결정하는 옵션
int나 date처럼 직관적인 자료형에서는 collation의 차이가 큰 의미는 없지만, 문자를 정렬하는것은 생각보다 어렵다.
따라서 텍스트 정렬할 때 사용한다.
자세히 말하자면!
int : 1000 < 1001
date : 2022-01-01 < 2022-12-12
-> 위의 두 형식은 명확하다.
하지만 text형은 어떨까?
a와 b중 큰 것은?
a와 A중 큰 것은? ...
-> 어떤 기준을 사용하느냐에 따라 달라지므로 결론을 내리지 못할것이다.
utf8_bin, utf8_general_ci, utf8_unicode_ci 세 가지 collaction을 확인해보자.
ASCII 코드표의 16진수 순서로 정렬.
A,B ..., a, b... 순서로 정렬됨
유니코드 표준을 기반으로 정렬.
유니코드는 전 세계에 존재하는 모든 문자 인코딩을 통합하려는 목적으로 제작되었기 때문에, 사람이 사용할 수 있는 거의 모든 언어들이 표현되어있음.
텍스트 정렬 시, a 다음에 b가 나타나야 한다는 생각에서 나온 정렬방식.
utf8_unicode_ci와 정렬 방법은 똑같지만, 정렬 속도 향상을 위해 일반적으로 잘 사용되지 않는 문자들을 정렬 기준에서 제외한 방법
잘 사용하지 않는 문자들(ÀÁÅåāă)을 모두 'A'와 같은 우선순위로 인식해서 정렬 수행속도를 빠르게 하자는 취지로 개발되었다.
요즘처럼 이모티콘을 많이 사용하는 시대에서, 일반적으로 어플리케이션을 만들고자 한다면, utf8mb4와 utf8mb4_unicode_ci를 사용하는 것이 좋다.
얼핏 설명을 들어보면 general_ci 를 사용하는 것이 더 현명해 보이지만 시대가 지나오면서 CPU의 성능이 상승하고 그에 따라 수행속도에 대한 이슈는 크게 중요하지 않아졌다.
하지만 오늘날에 서비스는 점점 더 세계화되고 모든 언어를 지원하는 것이 수행 성능보다 더 심각한 이슈로 받아들여지고 있기 때문에 unicode_ci를 사용하는 것이 더 좋다.
하지만! 만일 MySQL 5.5.3 이전 버전이라면 = utf8 character에 utf8_general_ci collation을 사용하자.