테이블 구조 디자인 문제

테이블 구조 디자인, 어떻게 해야 할지 모르겠습니다. 문의하세요:

아래에는 6가지 유형의 테이블이 포함된 모듈이 있으며, 모두 5~6개의 공통 필드가 있습니다. (각 테이블에는 3천만 개가 넘는 데이터가 있습니다)

1. 새 마스터 테이블을 생성하고 이 5개 필드를 구분한 후 로그 유형 ID를 추가하여 6개 테이블(제3정규형)을 작동하고 공동 쿼리를 수행합니다.

<code>优点：可以方便更新共同字段、统计数据
缺点：数据多了，联合查询是个问题
</code>

2. 별도의 테이블 6개

<code>优点：（查询单表不用联合、插入也方便一些)
缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
</code>

어떤 방법이 더 좋나요, 아니면 다른 제안이 있나요?

감사합니다!

답글 내용:

테이블 구조 디자인, 어떻게 해야 할지 모르겠습니다. 문의하세요:

아래에는 6가지 유형의 테이블이 포함된 모듈이 있으며, 모두 5~6개의 공통 필드가 있습니다. (각 테이블에는 3천만 개가 넘는 데이터가 있습니다)

1. 새 마스터 테이블을 생성하고 이 5개 필드를 구분한 후 로그 유형 ID를 추가하여 6개 테이블(제3정규형)을 작동하고 결합 쿼리를 수행합니다.

<code>优点：可以方便更新共同字段、统计数据
缺点：数据多了，联合查询是个问题
</code>

2. 별도의 테이블 6개

<code>优点：（查询单表不用联合、插入也方便一些)
缺点：统计和更新共同字段状态、以及做报表什么之类的都需要 一次性去操作6个表
</code>

어떤 방법이 더 좋나요, 아니면 다른 제안이 있나요?

감사합니다!

수량이 너무 많으면
테이블에 구축하고 동시에 데이터를 es로 전송합니다. 읽을 때
작업 테이블을 업데이트하고 업데이트된 데이터를 동시에 동기화합니다. .에서

질문이 명확하지 않습니다.

1. 6개 테이블의 관계는 무엇인가요? 공통 필드의 통계 업데이트를 위해 한 번에 6개의 테이블을 운영해야 하는 이유는 무엇인가요?

2. 지금은 어떤 모습이고, 성능은 어떤지, 어떤 질의문과 업데이트문이 나올지.

실제로 데이터가 3천만 개에 도달하면 테이블로 분할하는 것을 고려할 수 있습니다.

테이블로 분할하는 것이 더 좋습니다. 데이터 양이 많을 때는 테이블로 분할하는 것이 불가피하며, 분할 방법도 나쁘지 않습니다. 정기적인 검색의 필요성을 고려해야 한다면 정기적인 검색을 위한 조건을 사용하는 것을 고려해 볼 수 있습니다. 스토리지 분할 구조로 인해 통계 속도가 빨라질 수 있습니다. 상대적으로 검색량이 적은 다른 방법은 몇 번만 검색할 수 있습니다.

데이터의 양이 수천만 개에 달한다는 점을 고려하면 정기적으로 임시 통계 테이블을 생성하여 데이터베이스 부담을 줄이고 쿼리 통계 속도를 높이는 것을 고려할 수 있습니다.

어떤 시나리오 데이터인가요? 비즈니스 통계를 수행할 때 별도의 테이블에서 처리하는 것이 좋습니다. 문제를 해결하기 위해 반드시 많은 수의 테이블에 대해 데카르트 곱을 수행할 필요는 없습니다.