VarChar(191) 이유

Why does the String varchar length defaults to 191? · prisma/prisma · Discussion #17781

Why are database columns 191 characters?

블로그에 정리하였습니다.

[DB] Prisma에서 String VARCHAR의 길이는 어째서 varChar(191)일까?

번역 (기본 번역을 좀 더 깎음)

255는 191보다 훨씬 더 의미가 있습니다. 어떻게 191에 도달하게 되었나요? 이모티콘을 비난하겠습니다 😜. 첫 번째 이모티콘을 포함하는 문자 집합인 utf8mb4가 있었으니까요. 2000년대 초반의 MySQL은 바차르 열에서 255자를 지원하고 색인을 생성하는 데 만족했습니다. 그러나 가장 널리 사용되는 MySQL 데이터베이스 엔진(innodb)에서 가장 널리 사용되는 텍스트 인코딩(라틴1 또는 utf8)은 모든 문자 2 를 저장하는 데 3바이트가 충분하다고 가정했으며 , utf8mb4가 한자 및 🐟와 같은 문자가 등장하자 각 문자를 저장하는 데 4바이트가 필요했습니다. 선택할 수 있는 문자가 더 많았으므로 이를 참조하는 데 더 많은 바이트가 필요했습니다.

MySQL 데이터베이스가 작동하는 방식은 **innodb**인덱스에 대해 767바이트만 가질 수 있다는 것입니다. 이는 255개의 3바이트 문자( 767/3 = 255)를 저장하기에 충분합니다. 이는 인덱싱하는 데이터의 크기를 아는 것을 기반으로 한 인덱스 최적화의 극단적인 예입니다! 따라서 문자를 저장하는 데 더 많은 공간이 필요하다면 색인화할 수 있는 문자 수는 더 적어져야 합니다. 구체적으로는 **767/4 = 191**캐릭터! 더 많은 소프트웨어가 전 세계 고객을 지원함에 따라 기본값으로 varchar(191) 이 varchar(255) 를 대체하였습니다 . **varchar(255)**해외 사용자를 지원할 필요가 없는 소프트웨어 애플리케이션의 경우 2010년대 초 사용자가 이모티콘 지원(종종 스마트폰의 등장과 관련됨)을 기대하기 시작하면 업그레이드도 필요했습니다.

요즘에는 최신 데이터베이스에서 "모든" 문자를 지원할 수 있는 utf8mb4 등의 문자 인코딩이 기본값으로 사용되며, 고정 길이 인덱스는 이제 과거의 일이 되었습니다. 그러나 호환성을 보장하기 위해 많은 애플리케이션에서 여전히 191자의 기본값을 사용하고 있습니다. 어쨌든 인덱스는 비교 대상 문자열의 크기를 알고 있을 때 가장 잘 작동하므로 속도상의 이유로 열 길이에 어느 정도 제한을 두는 것이 좋으며, 역사와 관성 덕분에 191자 제한은 여전히 유지되고 있습니다.

한날 멘토님 피드백

1. 회원정보
   1. 식별자의 값 길이가 191인 건 어떤 의미에요? (질문)
      1. Prisma에서 회원정보의 경우 모델링을 해놓았는데 자동적으로 191로 잡혀서 일단 채워놨습니다.
      2. 호환성 문제
   2. 식별자와 소셜 타입은 서로 어떤 관계일까요? (질문 아님) 그 관계에서는 어떤 걸 고려해야 할까요? (== 고려 안 하면 어떤 문제가 발생할 수 있을까요?) (결합도)
      1. 현재 구글 로그인만 구현을 하고 있는데 식별자의 경우 구글에 등록되어있는 해당 사용자의 고유 넘버입니다. 이를 통해 사용자를 구분하려합니다. 소셜 타입의 경우 이후 만약 다른 OAuth를 추가하게 되었을 때 식별자 숫자가 혹여나 같은 상황이 발생할 수 있기 때문에 소셜 타입으로도 구분하였습니다.
   3. b에 더해서, 식별자와 소셜 타입은 응집도도 높이면 좋을 것 같아요. provider_id 와 social_type 만 봐서는 서로 연관된 것인지 알기 어려워요.
      1. 방법 모르겠음
   4. 만약 여러 provider를 제공한다면, 각 provider 별로 계정을 부여하는 건가요? (질문 || 질문 아님)
      1. 현재는 구글만 구현되어 있지만, 이후 다른 OAuth를 추가할 경우를 고려하여 중복을 방지하기 위해 소셜 타입으로도 구분하고 있습니다.
      2. 정하기 나름임 - 각자 다른 OAuth로 로그인 할 시 계정 자체가 달라지는게 일반적
   5. 화면에서 이용자를 드러내는 정보는 닉네임 하나인가요? (질문 아님)
      1. 맞습니다. 현재 구글에 등록되어있는 해당 사용자의 닉네임을 전달합니다.
2. 그룹, 참석자
   1. bridge table을 보면 연결 대상 table에 대해 FK를 걸었는데요. 정확한 의미는 두 FK 값에 대해 unique 해야 하는 거죠? 어, 잠깐. Key + Unique?
      1. 대답:
3. 모각코
   1. 인원 수는 “참석자“에 대한 합계라면, 정규화를 좀 더 해보시겠어요?
   2. 인원 수는 column type을 좀 더 알뜰한 걸로 써보아요.
      1. TINYINT가 제일 작아서 저 값을 사용하겠습니다.
   3. 주소는 상세 주소를 포함한 전체 주소인가요? 만약 지도로 위치를 찍어줄거라면 사람이 이상하게 넣는 주소를 어떻게 다룰지 고민해보셔요~
   4. 조회수는 어떤 용도에요? 엄밀하게 다뤄야 하는 정보인가요? 카운트 기준은 뭐에요? (질문)
      1. 제거하였습니다.
   5. 모델링에 대한 건 아니고, 사람들이 참석 신청한 상태에서 “날짜 및 시간” 등 모각코라는 모임(entity)의 속성을 변경하면 어떻게 대처해요? (질문)
      • 기획적으로 정한 것은 없음
      • 알림을 보내 주는 방식으로 대처? → 채팅으로?