더 효율적인 방법 : 여러 MySQL 테이블 또는 하나의 큰 테이블?

MySQL 데이터베이스에 다양한 사용자 세부 정보를 저장합니다. 원래는 데이터가 UserId와 연결되어 있고 필요에 따라 데이터를 표시하고 조작하는 복잡한 호출을 통해 출력하는 것을 의미하는 다양한 테이블에 설정되었습니다. 새로운 시스템을 설정하면 이러한 모든 테이블을 하나의 큰 관련 콘텐츠 테이블로 결합하는 것이 거의 합리적입니다.

• 이것이 도움이 될까요 아니면 방해가 될까요?
• 전화, 업데이트 또는 검색 / 조작시 속도 고려 사항?

다음은 내 테이블 구조의 일부 예입니다.

• users-사용자 ID, 사용자 이름, 이메일, 암호화 된 비밀번호, 등록 날짜, IP
• user_details-쿠키 데이터, 이름, 주소, 연락처 정보, 소속, 인구 통계 데이터
• user_activity-기여, 마지막 온라인, 마지막보기
• user_settings-프로필 표시 설정
• user_interests-타겟팅 가능한 변수 광고
• user_levels-액세스 권한
• user_stats-조회수, 집계

편집 : 지금까지 모든 답변을 찬성했으며 모두 본질적으로 내 질문에 대답하는 요소가 있습니다.

대부분의 테이블은 비정규 화의 주된 이유 인 1 : 1 관계를 가지고 있습니다.

이러한 셀의 많은 부분이 비어있을 가능성이있는 경우 테이블이 100 개 이상의 열에 걸쳐 있으면 문제가 있습니까?

여러 테이블은 다음과 같은 방법 / 사례에 도움이됩니다.

(a) 다른 사람들이 다른 테이블을 포함하는 응용 프로그램을 개발하려는 경우 테이블을 분할하는 것이 좋습니다.

(b) 데이터 수집의 다른 부분에 대해 다른 사람에게 다른 종류의 권한을 부여하려는 경우 분할하는 것이 더 편리 할 수 ​​있습니다. (물론 뷰를 정의하고 적절한 권한을 부여하는 방법을 살펴볼 수 있습니다.)

(c) 특히 개발 중에 데이터를 다른 위치로 이동하려면 테이블을 사용하여 파일 크기를 줄이는 것이 좋습니다.

(d) 더 작은 공간은 단일 엔티티의 특정 데이터 수집에 대한 애플리케이션을 개발하는 동안 편안함을 제공 할 수 있습니다.

(e) 가능성이 있습니다. 단일 값 데이터로 생각한 것이 미래에 실제로 여러 값이 될 수 있습니다. 예를 들어 신용 한도는 현재 단일 값 필드입니다. 그러나 내일 값을 (시작일, 종료일, 신용 값)으로 변경할 수 있습니다. 이제 분할 테이블이 유용 할 수 있습니다.

내 투표는 데이터가 적절하게 분할 된 여러 테이블에 대한 것입니다.

행운을 빕니다.

테이블 결합을 비정규 화라고합니다.

JOIN유지 관리 지옥을 만드는 대신 더 빠르게 실행 되도록 몇 가지 쿼리를 만드는 데 도움이 될 수도 있고 그렇지 않을 수도 있습니다 .

MySQL단지 사용 가능한 JOIN즉, 방법 NESTED LOOPS.

즉, 구동 테이블의 각 레코드 MySQL에 대해 루프의 구동 테이블에서 일치하는 레코드를 찾습니다.

레코드를 찾는 것은 순수한 레코드 스캔보다 수십 배가 걸릴 수있는 상당한 비용이 드는 작업입니다.

모든 레코드를 하나의 테이블로 이동하면이 작업을 제거하는 데 도움이되지만 테이블 자체가 커지고 테이블 스캔이 더 오래 걸립니다.

다른 테이블에 많은 레코드가있는 경우 테이블 스캔이 증가하면 순차적으로 스캔되는 레코드의 이점이 과중해질 수 있습니다.

반면에 유지 보수 지옥은 보장됩니다.

모두 1 : 1 관계인가요? 즉, 사용자가 다른 사용자 레벨에 속할 수 있거나 사용자 관심사가 사용자 관심 테이블에서 여러 레코드로 표시되는 경우 해당 테이블을 병합하는 것은 즉시 문제가되지 않습니다.

정규화에 대한 이전 답변에 대해서는 데이터베이스 정규화 규칙이 성능을 완전히 무시하고 깔끔한 데이터베이스 디자인이 무엇인지 살펴보고 있다고 말해야합니다. 그것은 종종 당신이 성취하고자하는 것이지만, 성능을 추구하기 위해 적극적으로 비정규 화하는 것이 합리적 일 때가 있습니다.

대체로 질문은 테이블에있는 필드의 수와 액세스 빈도에 달려 있습니다. 사용자 활동이 종종 그다지 흥미롭지 않은 경우 성능 및 유지 관리상의 이유로 항상 동일한 기록에 보관하는 것이 성가신 일이 될 수 있습니다 . 예를 들어 설정과 같은 일부 데이터가 자주 액세스되지만 단순히 필드가 너무 많은 경우 테이블을 병합하는 것도 편리하지 않을 수 있습니다. 성능 향상에만 관심이있는 경우 설정을 별도로 유지하고 데이터베이스를 자주 쿼리 할 필요가 없도록 자체 세션 변수에 저장하는 등의 다른 접근 방식을 고려할 수 있습니다.

수행 하는 모든 이들 테이블은 한 1-to-1관계는? 예를 들어 각 사용자 행에는 user_stats또는에 해당하는 행이 하나만 user_levels있습니까? 그렇다면 하나의 테이블로 결합하는 것이 합리적 일 수 있습니다. 그러나 관계 가 그렇지 않다면 1 to 1 그것들을 결합 (비정규 화)하는 것은 아마도 말이되지 않을 것입니다.

사용자 레코드가 수십만 또는 수백만 개가 아니라면 별도의 테이블과 하나의 테이블에 두는 것은 성능에 거의 영향을 미치지 않을 것입니다. 실제로 얻을 수있는 유일한 이점은 쿼리를 결합하여 쿼리를 단순화하는 것입니다.

ETA :

귀하의 경우 우려 하는 것에 대한 것입니다 너무 많은 열을 , 다음 생각 은 일반적으로 함께 사용하고 그 결합 물건 무엇을 (필요한 경우 또는 여러 개의 별도의 테이블) 별도의 테이블에 나머지를 떠나.

데이터를 사용하는 방식을 살펴보면 쿼리의 80 %가 해당 데이터의 20 %를 사용하고 나머지 80 %는 가끔씩 만 사용된다는 것을 알게 될 것입니다. 자주 사용하는 20 %를 하나의 테이블로 합치고, 자주 사용하지 않는 80 %는 별도의 테이블에 남겨두면 좋은 타협이있을 것입니다.

하나의 대규모 테이블을 만드는 것은 관계형 데이터베이스 주체에 위배됩니다. 나는 그것들을 모두 하나의 테이블로 결합하지 않을 것입니다. 반복되는 데이터의 여러 인스턴스를 얻을 것입니다. 예를 들어 사용자에게 세 가지 관심사가있는 경우 세 가지 다른 관심사를 저장하기 위해 동일한 사용자 데이터가있는 3 개의 행이 있습니다. 다중 '정규화 된'테이블 접근 방식을 선택하십시오. 데이터베이스 정규화에 대해서는 이 Wiki 페이지를 참조하십시오 .

편집 : 귀하의 질문을 업데이트했기 때문에 내 답변을 업데이트했습니다 ... 이후로 더 지금 내 초기 답변에 동의합니다 ...

이 세포의 많은 부분이 비어있을 가능성이 있습니다.

예를 들어 사용자가 관심사가없는 경우 정규화하면 해당 사용자에 대한 관심 테이블에 행이 없습니다. 하나의 방대한 테이블에 모든 것이 있으면 NULL 만 포함하는 열 (그리고 분명히 많은 열)이 있습니다.

나는 수많은 테이블이있는 전화 통신 회사에서 일했으며 데이터를 얻으려면 많은 조인이 필요할 수 있습니다. 이러한 테이블에서 읽기 성능이 중요 할 때 보고서가 가리킬 수있는 조인, 계산 등이 필요없는 플랫 테이블 (예 : 비정규 화 된 테이블)을 생성 할 수있는 프로 시저가 생성되었습니다. 그런 다음 SQL 서버 에이전트와 함께 사용하여 특정 간격으로 작업을 실행합니다 (예 : 일부 통계의 주간보기는 일주일에 한 번 실행 됨).

모든 사람이 가지고있는 기본 사용자 정보가 포함 된 사용자 테이블을 만든 다음 기본적으로 사용자 ID와 관련된 모든 키, 값 쌍이 될 수있는 "user_meta"테이블을 추가하여 Wordpress가 수행하는 것과 동일한 접근 방식을 사용하면 안됩니다. 따라서 사용자에 대한 모든 메타 정보를 찾아야하는 경우 쿼리에 추가하면됩니다. 또한 로그인과 같은 작업에 필요하지 않은 경우 항상 추가 쿼리를 추가 할 필요는 없습니다.이 접근 방식의 이점은 사용자에게 Twitter 핸들 또는 각 개별 관심사를 저장하는 것과 같은 새로운 기능을 추가 할 수 있도록 테이블을 열어 둡니다. 또한 모든 메타 데이터를 지배하는 하나의 테이블이 있고이를 50 개가 아닌 하나의 연결로 제한하기 때문에 연결된 ID의 미로를 처리 할 필요가 없습니다.

Wordpress는 특히 플러그인을 통해 기능을 추가 할 수 있도록이 작업을 수행하므로 프로젝트의 확장 성을 높이고 새 기능을 추가해야하는 경우 완전한 데이터베이스 점검이 필요하지 않습니다.

나는 이것이 그러한 "의존적"상황 중 하나라고 생각합니다. 여러 테이블을 갖는 것이 더 깨끗하고 이론적으로 더 좋습니다. 그러나 단일 사용자에 대한 정보를 얻기 위해 6-7 개의 테이블을 조인해야하는 경우 해당 접근 방식을 다시 생각하기 시작할 수 있습니다.

다른 테이블이 실제로 무엇을 의미하는지에 따라 다릅니다. user_details에 사용자가 1 명 이상 포함되어 있습니까? 요구 사항에 가장 적합한 정규화 수준은 요구 사항에 따라 다릅니다.

좋은 인덱스를 가진 테이블이 하나 있다면 아마도 더 빠를 것입니다. 그러나 다른 한편으로는 유지하기가 더 어려울 것입니다.

나에게 User_Details는 아마도 사용자와 1 : 1 관계이므로 건너 뛸 수있는 것처럼 보입니다. 하지만 나머지는 아마도 사용자 당 많은 행일까요?