답변:
당신은 당신이 할 수있는 한 멀리 나아가 야합니다. 당연하지. ~ 문제는 이것이 약간의 예술이며 이것이 순수한 과학이 아닌 이유입니다.
당사의 주요 제품은 분석 및보고 시스템이므로 이와 관련하여 몇 가지 세부 기록이 있습니다. 우리는 처음에 일부 하위 레코드의 공통 ID로 많은 조인을 사용하도록 설계했지만 몇 개의 필드를 비정규 화하면 많은 조인을 잘라 내고 많은 성능 문제를 해결할 수 있음을 알았습니다.
그러나 우리는 1) "정규화 된"디자인을 만들고 2) 디자인을 사용하기 시작했기 때문에 3) 수십 개의 테이블에서 수억 행에 이르는 실제 성능을 프로파일 링했다는 사실 만 알았습니다.
마지막 이야기는 우리가 프로필을 작성하기 전까지는 무엇이 우리에게 도움이 될지 확신 할 수 없었습니다. 더 쉽게 업데이트 할 수 있도록 정규화 아이디어가 마음에 들었지만 결국 실제 성능이 결정적인 요소였습니다. 그것은 당신을위한 나의 충고입니다 : 프로필, 프로필, 프로필.
in ('forgiven','pardoned');) : p
정규화는 데이터 모델을 충분히 지원할 수있는 경우에만 목표입니다. 성장, 관리 및 유지 관리를 지원하기위한 지침이 될 것입니다. 정규화에 대한 책이나 필자가 데이터베이스 나 응용 프로그램을 작성하거나 유지 관리한다는 것을 기억하십시오.
"너무 많은 정규화"라는 주제에 대해 잘 읽어 보았습니다.
그리고 너무 많은 정규화에 성능 영향이있을 수 있습니다. 이것은 상태 표시기 테이블과 같은 것을 별도의 테이블로 가져올 때 가져 오기 위해 더 깊은 테이블 순회에 있습니다. 일부는 업데이트 속도 (상태 텍스트를 "Good"에서 "GOOD"또는 이와 유사한 것으로 변경) 또는 유지 보수성에서 일반적으로 무시된다고 말합니다.
Chris Date 에서 찾은 다음 부록을 읽는 것이 좋습니다. 의 최근 저서 .
정규화는 만병 통치약과는 거리가 멀다. 우리는 목표가 무엇인지, 목표에 얼마나 잘 부합하는지 쉽게 알 수 있기 때문에 ...
이 섹션의 설명이 어떤 종류의 공격으로도 표시되지 않도록해야합니다. 나는 완전히 정규화 된 디자인보다 적은 것은 금기 사항이라고 굳게 믿습니다 ...
나는 @jcolebrand에 전적으로 동의합니다. 애플리케이션을위한 모델을 설계 할 때는 가능한 모든 것을 정규화해야합니다. 그러나 모델을 통해 작성된 쿼리, 특히 자주 실행되는 쿼리를 프로파일 링해야합니다.
내 자신의 경험 : 두 개의 조인에 도달 한 속성 (즉, 세 개의 테이블이 조인 됨)은 대부분 성능을 저하시킵니다. 최악의 경우 온라인 거래에 사용됩니다. 속성을 비정규 화 했으므로 하나의 조인이 필요하며 프로그래머에게 쿼리에 대한 앱을 조정하고 속성을 업데이트하도록 요청했습니다. 이제 훨씬 잘 작동합니다 ...
다시 말해 정규화와 성능의 균형을 유지해야합니다.