DB 설계 및 성능 : 중복 FK를 사용하여 성능을 향상시킬 수 있습니까?

Question

내가 DB 구조를 다음했다 말할 수 있습니다 :

을 내 응용 프로그램은 모든 세부 사항 (모델, 제품군, 브랜드, 프로듀서)와 함께 물품의 목록을 표시 할 필요가있다. 이를 위해서는 필요한 데이터를 얻기 위해 더 많은 JOIN을 만들어야합니다.

다음과 같이 Article 테이블에 중복 FK를 생성하여 응용 프로그램의 성능을 향상시키는 것이 좋습니까? 실제로 성능이 향상됩니까?

Answer 1

예 수 증가 성능 계층 구조에서 "중간"개체의 데이터를 검색하지 않으려면 그 방법. 이것은 비정규 화의 일반적인 형태입니다. 불일치가 발생하지 않도록주의해야합니다.

대개 비정규 화 된 데이터 인을 확인하고 메일 오류를 확인하고 자동으로 수정하는 야간 작업을 밤에 설정합니다. 이것은하기가 어렵지 않고 불쾌한 클래스의 버그를 제거합니다.

사람들이하는 다른 이유는 파티션 같은 키의 모든 테이블에 있습니다.

Answer 2

디자인이 성능을 향상시키는 지 확인하는 가장 좋은 방법은 시도하는 것입니다. 두 번째로 좋은 방법은 실행해야 할 가능성이있는 쿼리를 생각한 다음 머리 속에 모델화하는 것입니다. 실행하려는 쿼리 또는 데이터베이스의 크기를 알지 못하면 성능 향상 여부를 알기가 어렵습니다.

매우 일반적인 용어로, 매우 큰 데이터베이스를 사용하지 않으면 성능에 대한 측정 가능한 영향을 볼 수 없다고 말할 수 있습니다 (적절한 하드웨어에서이를 실행하고 인덱스를 조정했다고 가정) . "매우 큰"으로, 나는 여러 테이블에서 수백만 행을 생각하고 있습니다.

만약 당신이 정말로 de-normalize 할 필요가 있다면, 나의 충고는 여분의 키들로 정규 디자인을 "오염시키는"것이 아니라 명시 적으로 비정규 화 된 테이블을 만드는 것이다. 두 가지를 섞어 쓰는 대신 "해야할 일"과 "타협"을 구분하는 디자인을 이해하는 것이 훨씬 쉽습니다.

그것을 달성하기 위해, 나는 별도의 테이블 만들 것 - 아마도 "cached_articles", 열 :

article_id 
...(article data) 
model_id 
....(model data) 
family_id 
...(family data) 
brand_id 
....(brand data) 
producer_id 
....(producer data) 

당신은 일괄 작업 또는 트리거를 통해이 테이블을 유지 할 수 있습니다. 애플리케이션 코드는 정규화 된 테이블에 쓰기 만하고 필요할 때 캐시 테이블에서 읽어야합니다.

또한 응용 프로그램을 중단시킬 수있는 데이터 문제를 식별하는 강력한 "일관성 검사"메커니즘을 구축해야합니다. 이러한 일관성 검사는 동일한 성능 문제가 발생하기 때문에 데이터베이스가 이러한 종류의 디자인이 필요한 크기로 커지면 큰 문제가됩니다. ...