데이터베이스 정규화로 확장 성이 저하됩니까?

Question

고도로 트래 피킹 된 웹 앱의 일부가 될 데이터베이스가 있습니다.

예를 들어 'question_type'같은 것들이 'title'과 'question_body'와 같은 질문에 대한 기본 정보가 아닌 별도의 테이블에 있어야하므로 테이블을 정규화해야할까요?

나는이 데이터베이스가 가능한 확장 성이 있어야하고 확장 성이 필요할 때 정규화가 항상 진행되는 것은 아니기 때문에 내가 묻는 것입니다.

감사

Answer 1

스케일링에 문제가 여러 테이블이 함께 가입이 필요 경향이 있다는 것입니다 정상화를 만드는 것. 조인은 작은 테이블에서는 훌륭하지만 테이블이 커질수록 서버가 더 많이 작동해야합니다.

중요한 것은 조인을 피하는 것입니다. 테이블 중 하나에 필드를 추가하여 조인없이 쿼리를 수행 할 수 있다면 그 쿼리의 성능을 향상시킬 수 있습니다.

Answer 2

소금을 추가하면 음식 맛이 좋아 지나요?

같은 질문입니다. 아무도 대답 할 수 없습니다.

USAGE 패턴에 따라 다르며 프로그래머로서의 역량을 키우는 데있어 데이터베이스 조인 대신 응용 프로그램에서 조회 캐시를 사용하는 것이 좋습니다. 상당수의 프로그래머는 요리의 비유를 유지하기 위해 "스크램블 드 에그, 레코딩 된"SQL 수준을 넘지 않습니다.

확장 성 응용 프로그램 설계 및 데이터베이스 기술에 대해 더 많은 이야기가 있습니다. Oracle RAC 설치를 이기기가 어렵습니다. Exadata 플랫폼에서 필요한 항목에 따라 다릅니다. 비용은 제가 생각하기에 가장 작은 단위로 약 50 만 달러입니다. 여전히 "가능한 확장 가능"해야합니까? 여기서 농담하지 마라. 나는 지금 6000GB 데이터웨어 하우스에서 작업한다. 우리는 단지 그 중 3 대를 주문했다.

"가능한 한 확장 가능"이란 무엇을 의미합니까? 이것은 마치 내 차가 이제까지 갈 차보다 더 빨리 갈 필요가 있습니다. 그러면 제트 엔진이 달린 특수 제작 된 차로 끝납니다;)

일반 규칙 : * 별도 거래 및 두 개의 데이터베이스로보고. 두 번째는 데이터웨어 하우스입니다. * 트랜잭션 db 정상화 * 데이터웨어 하우스에서 스타 스키마 사용.

큰 기회 : 당신이 말한 것을 잘 모르겠지만 확장 성을 전혀 해보지 않았으므로 "높은 확장 성"요구 사항은 괜찮은 데이터베이스 서버의 농담입니다. 이제 그건 모욕적 인 의미는 아니지만 많은 사람들이 "나는 테이블에 1 톤의 데이터를 가지고 있습니다"라고 말하면서 최대 10.000 행이되는 것을 보았습니다. 그것은 톤이 아닙니다. 농담입니다. 우리는 데이터웨어 하우스 메인 테이블에 매일 1 억을로드합니다 (수년간 유지해야합니다). 대부분의 사람들은 괜찮은 데이터베이스 서버가 제공 할 수있는 속도를 얻지 못합니다. 많은 디스크를 의미합니다.

Answer 3

이제로드 된 질문입니다. 정규화는 가이드 라인만큼 어려운 것이 아닙니다. 데이터베이스 설계는 코드 효율, 성능 및 무결성에 대한 필요성을 감안한 정상화 수준에 관한 일련의 결정으로 구성됩니다. 이는 그것을 극도로 간소화하지만, 디자인 결정의 범위는 잘 작성된 책의 양을 포괄합니다.

응용 프로그램과 원하는 플랫폼에 대해 좀 더 알려 줄 수 있습니까?나는 당신의 상황을 더 잘 이해할 수 있다면 당신을 매우 유용한 참고 자료의 방향으로 안내 할 수있을 것입니다.

Answer 4

테이블에 question_body 및 question_type이있는 경우 다른 테이블로 이동하면 정규화가 어떻게되는지 알 수 없습니다. 예 :

table question (
    question_body  text, 
    question_user  text, 
    question_user_rank integer, 
    question_type  text 
); 

하나의 값을 단일 열 테이블로 나누는 것은 쓸모없는 조인 이외의 것을 얻지 못합니다. 즉 :

select * from question q join question_type qt on (q.qt_id = qt.id) 
    where qt.name = 'sql questions'; 

(위의 예를 사용하여) 한편

select * from question 
    where question_type = 'sql questions'; 

의 등가이지만 낭비 형태, 그 질문에 사용자 정보를 분할하는 것이 많은 수있다 자신의 테이블로 : 사용자가있는 경우

table question (
    question_body  text, 
    question_type  text, 
    question_user_id integer references question_user(id) on delete cascade 
); 
table question_user (
    id    integer, 
    name    text, 
    rank    integer 
); 

그래서 그의 순위는, 당신은 단지 한 곳에서가 아니라 그가 질문을있어 모든 행에서 변경해야합니다 (SO ALA)이 변경되었습니다. 당신은 을 증가 시켰습니다. 수백 가지의 업데이트를 단일 업데이트로 변경했기 때문에 스케일링을 처리 할 수있는 능력이 있습니다.