70 개 이상의 열이있는 테이블을 설정하고 있습니다. 이제 테이블에 액세스 할 때마다 열의 일부 데이터가 필요하지 않으므로 분할을 고려하고 있습니다. 그런 다음 다시 이렇게하면 조인을 사용해야합니다.
어떤 시점에서 너무 많은 열로 간주됩니까?
답변
데이터베이스에서 지원 하는 최대 한도를 초과 하면 너무 많은 것으로 간주 됩니다 .
모든 쿼리에서 모든 열을 반환 할 필요가 없다는 사실은 완전히 정상입니다. 이것이 SELECT 문을 사용하여 필요한 열의 이름을 명시 적으로 지정할 수있는 이유입니다.
일반적으로 테이블 구조는 도메인 모델을 반영해야합니다. 실제로 동일한 엔터티에 속하는 70 개 (100 개) 속성이있는 경우이를 여러 테이블로 분리 할 이유가 없습니다.
답변
테이블을 더 적은 수의 열로 여러 개로 분할하면 몇 가지 이점이 있습니다.이를 수직 분할 이라고도 합니다. 다음은 몇 가지입니다.
-
행이 많은 테이블이있는 경우 MySQL이 테이블의 모든 인덱스를 다시 작성해야하므로 인덱스를 수정하는 데 시간이 오래 걸릴 수 있습니다. 인덱스를 여러 테이블로 분할하면 더 빠르게 만들 수 있습니다.
-
쿼리 및 열 유형에 따라 MySQL은 디스크에 임시 테이블 (보다 복잡한 선택 쿼리에 사용됨)을 기록 할 수 있습니다. 디스크 I / O가 큰 병목 현상이 될 수 있기 때문에 이것은 나쁘다. 쿼리에 이진 데이터 (텍스트 또는 Blob)가있는 경우에 발생합니다.
너무 일찍 최적화하지 마십시오. 그러나 경우에 따라 더 좁은 테이블에서 개선을 얻을 수 있습니다.
답변
정규화 규칙을 위반하면 너무 많습니다. 데이터베이스를 정규화하는 경우 많은 열을 가져 오는 것은 매우 어렵습니다. 특정 db 플랫폼에 대한 최적화에 대한 인위적인 규칙이나 아이디어가 아닌 문제를 모델링하도록 데이터베이스를 설계하십시오.
다음 규칙을 와이드 테이블에 적용하면 단일 테이블에 훨씬 적은 수의 열이있을 수 있습니다.
- 반복되는 요소 또는 요소 그룹 없음
- 연결된 키에 대한 부분적 종속성 없음
- 키가 아닌 속성에 대한 종속성 없음
여기 에 도움 이되는 링크 가 있습니다.
답변
모든 속성이 동일한 엔티티에 속하고 서로 의존하지 않는 한 문제가되지 않습니다. 삶을 더 쉽게 만들기 위해 JSON 배열이 저장된 하나의 텍스트 열을 가질 수 있습니다. 매번 모든 속성을 얻는 데 문제가 없다면 분명히. 이것은 RDBMS에 저장하는 목적을 완전히 무너 뜨리고 모든 데이터베이스 트랜잭션을 크게 복잡하게 만들 수 있습니다. 따라서 데이터베이스 전체에서 따르는 것은 권장되지 않는 접근 방식입니다.
답변
동일한 테이블에 너무 많은 열이 있으면 복제에도 큰 문제가 발생할 수 있습니다. 마스터에서 발생하는 변경 사항이 슬레이브에 복제된다는 점을 알아야합니다. 예를 들어 테이블에서 하나의 필드를 업데이트하면 전체 행이 w가됩니다.
답변
