MySQL 에서 흔히 볼 수 있 는 데이터 시트 디자인 오류 집합

오류 1:과도 한 데이터 열
MySQL 저장 엔진 의 API 는 서버 와 저장 엔진 에서 줄 버퍼 방식 으로 데 이 터 를 복사 합 니 다.서버 에서 버퍼 데 이 터 를 데이터 열 로 디 코딩 합 니 다.그러나 줄 버퍼 의 형식 을 데이터 줄 데이터 구조 로 바 꾸 는 열 은 대가 가 높 을 수 있 습 니 다.MyISAM 은 서버 와 일치 하 는 줄 형식 을 고정 적 으로 사용 하기 때문에 변환 할 필요 가 없습니다.그러나 MyISAM 의 가 변 줄 형식 과 InnoDB 의 줄 형식 은 항상 변환 이 필요 하 다.전환 의 대 가 는 열의 수량 에 의존한다.데이터 시트 의 열 이 백 열 을 넘 으 면 높 은 CPU 자원 소 모 를 일 으 킬 수 있 습 니 다.사용 하 는 열 이 적 더 라 도.한 편의 글 을 본 적 이 있 는데 이것 은 다 중 언어의 해결 방안 을 가리 키 며 시스템 이 지원 하 는 언어 를 직접적 으로 간단하게 대응 하 는 열 로 표시 하 는 것 을 말한다.예 를 들 어:

CREATE TABLE t_multi_language_news (
  id INT PRIMARY KEY,
  title_cn VARCHAR(32),
  title_en VARCHAR(32),
  title_it VARCHAR(32),
  ...
  content_cn VARVHAR(256),
  content_en VARCHAR(256),
  conntent_it VARCHAR(256),
);

이런 방식 은 시스템 이 지원 하 는 언어 가 많 을 수록 데이터 시트 의 열 이 많 을 수록 결국 성능 이 심각하게 떨어진다.만약 당신 이 데이터 시트 의 열 수량 이 100 을 초과 한다 면,당신 의 디자인 이 합 리 적 인지 아 닌 지 를 고려 해 야 합 니 다.**대응 방식:**먼저 업무 자체 의 디자인 이 합 리 적 인지 고려 하 는 것 입 니 다.만약 에 하나의 실체 가 많은 필드 를 필요 로 한다 면 데이터 표를 나 누 어 확장 정보 표를 통 해 할 수 있 습 니 다.예 를 들 어 정보 류 의 데이터 시트 는 내용 이 일반적으로 차지 하 는 공간 이 비교적 크 지만 목록 에서 직접 보지 않 으 면 정보 메 인 시트 와 정보 상세 표 로 뜯 을 수 있 고 메 인 표 는 제목,시간,요약,미리 보기 그림 첨부 id 등 목록 에서 볼 정 보 를 저장 하면 된다.정보 상세 한 내용 은 정보의 내용,출처,원문 링크 등 정 보 를 저장 할 수 있다.
오류 2:과도 한 공동 조회
MySQL 의 한 번 공동 조 회 는 최대 61 장의 표 만 있 을 수 있다.일부 디자인 은 불필요 한 필드 설 계 를 하지 않 으 면 복잡 한 업 무 를 할 때 여러 장의 표를 연결 하여 조회 해 야 한다 고 주장 한다.연합 표 수가 61 개 보다 적 더 라 도 성능 이 떨 어 지고 전체 SQL 문장의 유지 가 어려워 질 것 이다.디자인 의 가장 중요 한 원칙 은 속 도 를 추구 하려 면 한 번 의 조회 가 너무 많은 데이터 시트 를 넘 어 공동 조 회 를 하지 않 는 것 이다.특히 높 은 병행 장면 에 직면 할 때.**대응 방식:**우선,변경 되 지 않 는 필드 를 확인 하 는 데 있어 서 불필요 한 필드 를 고려 하여 공동 조 회 를 줄 일 수 있 습 니 다.예 를 들 어 한 기업 의 소속 성 정 보 는 성 코드,성 이름 을 불필요 하 게 할 수 있 고 성 코드 를 통 해 성 이름 을 조회 할 필요 가 없다.그 다음으로 다른 표를 찾 아야 하 는 상황 에서 단계별 조회 방법 을 고려 하여 응용 프로그램 을 통 해 데이터 조립 을 완성 할 수 있다.이런 효율 은 데이터 시트 가 많 을 때 더욱 효율 적 이 고 코드 도 잘 유지 된다.오류 3:만능 의 예 를 들 어 다음 과 같은 표 디자인:

CREATE TABLE t_countries (
  ...
  country ENUM('', '1', '2', ..., '45'),
  ...
);

이런 방식 은 원래 정 수 를 키 로 하 는 사전 검색 표를 통 해 이 루어 질 수 있 었 다.업무 상 매 거 진 이 추가 되 었 다 면 표 전체 가 ALTER TABLE 로 업데이트 되 어야 한 다 는 뜻 이다.응용 코드 를 사용 한 검색 표 라면 새로운 키 값 만 추가 하면 됩 니 다.**대응 방식:**매 거 진 이 변경 되 지 않 음(예 를 들 어 성별)이 확실 하 다 면 문제 없습니다.매 거 가 늘 어 날 수 있다 면 가능 한 한 응용 프로그램 을 통 해 이 루어 진다.
오류 3:ENUM 대신 SET 남용
매 거 진 ENUM 형식 은 데이터 테이블 의 값 이 값 집합 중의 하나 일 뿐 이 며,SET 형식 은 이 열 에 하나 이상 의 값 이 있 을 수 있 습 니 다.한 열 에 한 개의 값 만 있 는 것 이 확실 하 다 면 집합 이 아 닌 매 거 진 을 우선 사용 해 야 한다.예 를 들 어 다음 의 예 는 전형 적 인 남용 이다.

CREATE TABLE t_payment_way (
  ...
  is_default SET('Y', 'N') NOT NULL DEFAULT 'N',
  ...
);

분명 하 다default 는 Y 이거 나 N 이기 때문에 ENUM 을 사용 해 야 합 니 다.**대응 방식:**업무 차원 에서 열 거 된 값 이 여러 개 일 수 있 는 지,선택 할 수 있 는 값 이 1 개 밖 에 없다 면 매 거 진 ENUM 을 사용 합 니 다.
오류 4:NULL 을 무뚝뚝 하 게 피하 기
많은 글 들 이 가능 한 한 NULL 사용 을 피 하 는 것 에 대해 논 의 했 습 니 다.대부분의 장면 에 대해 좋 은 디자인 입 니 다.우 리 는 0,빈 문자열,약 정 된 값 등 을 통 해 빈 값 을 표시 할 수 있 습 니 다.그러나 이것 때문에 딱딱 하 게 사용 하지 마 세 요.이 값 자체 가 무의미 한 값 일 때 NULL 을 사용 하 는 것 이 더 적합 할 수 있 습 니 다.예 를 들 어-1 이 의미 없 는 정 수 를 대표 하면 코드 가 복잡 하고 bug 를 일 으 킬 수 있 습 니 다.예 를 들 어 다음 의 예:

CREATE TABLE t_person (
  birthday DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  ...,
);

하나의 DATETIME 유형의 기본 값 을 모두 0 으로 설정 하 는 것 은 이상 할 것 이다.만약 에 우리 가 인원 의 연령 평균 치 를 통계 하려 고 할 때 이상 한 문 제 를 일 으 킬 수 있다 고 가정 하면 이런 장면 은 NULL 을 사용 하면 통계 에 포함 되 지 않 을 것 이다.MySQL 을 설정 할 수 있 는 SQLMODE 매개 변 수 는 무의미 한 날 짜 를 사용 하 는 것 을 금지 하고 이러한 상황 이 발생 하지 않도록 합 니 다.**대응 방식:**테이블 을 디자인 할 때 는 NOT NULL 을 사용 하여 빈 값 을 피 할 수 있 지만 너무 딱딱 하지 않 습 니 다.일부 필드 에 서 는 기본 값 을 사용 하여 이름 의 의 미 를 표시 할 수 없 거나 실제 와 일치 하지 않 을 때 도 NULL 열 을 선택 할 수 있 습 니 다.다만,색인 열 에 NULL 을 사용 하지 않도록 주의해 야 합 니 다.실제로 대부분의 색인 열 이 NULL 일 리 가 없다.
오류 5:정수 교체 시간 스탬프 사용
이전에 시간 형식 을 어떻게 선택 하 는 지 에 대한 문제 가 있 었 는데 실제로 일부 개발 자 들 은 정수 로 시간 스탬프 를 저장 하 는데 그들의 이 유 는 이렇게 효율 이 높다 는 것 이다.어떤 의미 에서 보면 효율 이 조금 높 아 질 수 있 지만 도움 이 되 지 않 습 니 다.MySQL 내부 의 DATETIME 과 TIMESTAMP 자체 가 정수 로 저장 되 어 있 기 때 문 입 니 다.만약 에 정수 저장 시간 을 사용한다 면 응용 프로그램 에서 시간 전환 을 해 야 하거나 SQL 문 구 를 지정 한 필드 에 시간 전환 을 해 야 하기 때문에 수익 이 얻 는 것 보다 잃 는 것 이 많 을 수 있 습 니 다.**대응 방식:**가능 한 한 DATETIME 저장 시간 을 사용 하고 초 단위 의 정밀 도 를 저장 하 는 시간 이 필요 하 다 면 BIGINT 를 사용 하여 저장 하 는 것 을 고려 할 수 있 습 니 다.
오류 6:잊 어 버 린 필드 의 최대 저장 범위
실제 에서 표를 디자인 할 때 데이터 유형의 저장 범 위 를 잊어버린다.예 를 들 어 TINYINT(2)를 사용 하면 두 개의 정수 만 저장 할 수 있 는 것 이 아니 라 실제 TINYINT(2)가 저장 할 수 있 는 범 위 는-128-127 이다.255 가 넘 는 정 수 를 저장 하 다.이러한 오 류 는 정수 형식 을 사용 할 때 문제 가 발생 하기 쉽다.정 수 를 삽입 할 때 MySQL 은 실제 정수 자릿수 를 검사 하지 않 고 해당 저장 바이트 수의 범위 에 따라 저장 하 는데 이런 경우 주의 하지 않 으 면 무의미 한 값 이 저 장 될 수 있다 고 가정 한다.예 를 들 어 아래 의 INSERT 작업 이 성공 할 것 이 고 우 리 는 TINYINT(2)가 두 개의 정수 만 저장 할 수 있다 고 착각 할 수 있 습 니 다.

CREATE TABLE t_int_test (
    id INT PRIMARY KEY,
    number TINYINT(2)
);

INSERT INTO t_int_test (id, number) VALUES (3,123);

대응 방식:응용 프로그램 에서 데이터 검 사 를 합 니 다.
결어:
실제 데이터 시트 를 디자인 하 는 과정 에서 각 필드 의 데이터 형식 을 고려 해 야 할 뿐만 아니 라 저장 공간 크기 도 고려 해 야 한다.자주 사용 하 는 필드,예 를 들 어 시간,제목,비고 등 은 내부 에서 일정한 규범 을 형성 하 는 것 이 좋 습 니 다.여러분 은 규범 에 따라 집행 하고 검증 을 늘 리 면 많은 문 제 를 피 할 수 있 습 니 다.
이상 은 MySQL 에서 흔히 볼 수 있 는 데이터 시트 디자인 오류 집합 에 대한 상세 한 내용 입 니 다.MySQL 데이터 시트 디자인 오류 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 하 시기 바 랍 니 다!