데이터베이스에서 플래그 / 열을 정수 대신 문자열로 저장하는 이유는 무엇입니까?

Drupal 7, Wordpress (일부 매우 오래된 버전) 및 Python 기반의 사용자 정의 응용 프로그램을 포함한 유명한 CMS의 SQL 덤프를 탐색했습니다.

이러한 덤프에는 모두 정수 대신 문자열 플래그가있는 데이터가 포함되어 있습니다. 예를 들어, 게시물의 상태로 표현 된 published, closed또는 inherit보다는 1,2 또는 3.

나는 데이터베이스 디자인에 대한 경험이 제한되어 있고 간단한 SQL을 지나친 적이 없지만 항상 이와 같은 데이터에 숫자 / 정수 플래그를 사용해야한다고 배웠습니다. tinyint예를 들어 데이터베이스보다 공간을 훨씬 적게 소비 하는 것이 분명합니다 varchar(9).

그래서 내가 무엇을 놓치고 있습니까? 이것이 데이터 저장 및 데이터 중복을 낭비하지 않습니까? 이러한 열이 문자열 대신 정수를 사용하면 탐색, 검색 및 색인 생성이 조금 더 빠르지 않습니까?

예, 숫자 대신 문자열을 저장하면 더 많은 공간을 사용할 수 있습니다. 어쨌든 하이 프로파일 pltforms가 수행하는 이유는 솔루션의 이점이 비용보다 크다고 생각하기 때문입니다.

장점은 무엇입니까? 열거 형 테이블을 기억하지 않고도 데이터베이스 덤프를 쉽게 읽고 그 내용을 이해할 수 있으며, 반 공식 GUI조차도 단순히 레코드를 변환하는 대신 테마 값을 사용할 수 있습니다. (이것은 기본 디스크 공간 / 처리 시간 교환 형식입니다.)

비용은 어떻습니까? 디스크가 너무 크고 저렴하여 데이터 스토리지 용량이 CMS에서 오랫동안 병목 현상을 일으키지 않았습니다. 반면 프로그래머 시간은 일반적으로 비용이 많이 들기 때문에 디스크 공간에 대한 개발 노력 을 바꾸는 것은 비즈니스 관점에서 좋은 일입니다.

네, 같은 물건을 저장 yes하거나 true더 작은 공간보다 더 많은 공간을 차지할 것입니다. 이것은 놀라운 일이 아닙니다. 또한 인덱싱을 수행하므로 데이터베이스의 조인 효율이 떨어집니다. 또한 올바른 값 ( yesvs y) 이 무엇인지 혼동 될 수 있습니다 .

그러나 효율적인 데이터베이스 (특히 MySQL)에 문자열을 저장하는 것과 유사한 많은 접근 방식이 있습니다.

첫째, MySQL에는 enum유형 ( docs )이 있으며, 이러한 방식으로 설정하면 부울 또는 제한된 문자열 세트와 매우 유사합니다. 또한 유효한 값만 입력해야합니다. 이 저장보다 종종 훨씬 더 유용 1, 2또는 3같은 값으로 의미 있는 정보로 전달된다. 열거 형에는 유형을 추가하거나 제거하기 위해 스키마 변경이 필요하다는 단점이 있습니다.

이를 통해 자식 테이블과 외래 키 (모든 데이터베이스에 적용 가능)가 나타납니다. 예, 당신은 키합니다 (다시 같은 일부 값을 저장하는 1, 2또는 3)과의 값을 published, closed그리고 inherit다른 테이블에 저장됩니다. 뷰 ( docs )를 사용하면 테이블이 키가 아닌 문자열을 포함하는 것처럼 보이게 할 수 있습니다. 이는 자식 테이블에서 항목을 추가하거나 제거하기 위해 스키마를 변경할 필요가 없다는 장점이 있습니다.

정확하게 물건을 저장하는 방법은 스키마의 실제 DDL을보고 어떤 방법이 사용되는지 결정하고 어떤 트레이드 오프를 선택했는지에 대한 힌트를 얻어야합니다.