0

현재 데이터베이스 설계 중입니다. 우리는 잘 설계되지 않은 기존 시스템을 가지고 있으며 명확하게 볼 수있는 모든 작은 문제를 다림질하고 있습니다. bit 대신 true/false 플래그의 경우 varchar입니다.DB 설계 및 성능

내가 알고 싶은 것은 달콤한 데이터베이스 디자인이 있다는 것을 어떻게 알 수 있습니까? 아니면 이것이 신화인가? 제 말은, 구조가 종이에 놀라 울 정도로 보일 수도 있지만, 일부 데이터가있을 때 어떻게 수행 할 것인가하는 것입니다.

"lookup"값을 저장하는 테이블이 전체 설명 텍스트를 저장하는 것보다 빠릅니까? 예 : 이 시나리오에서는

오류 테이블

Id ErrorId DateCreated 
1  1   09/12/2011 
2  5   10/12/2011 

오류 설명 테이블

Id Description 
1  Warning - failed to validate 
2  Failed to locate file 

하는 view 필요한 조인을 포함하여 SQL을 쓰는 것보다 더 도움이 될 만드는 것?

죄송합니다.이 질문을 잘못된 위치에 게시했습니다.

+0

실제로 해 보았습니까? –

답변

0

"lookup"값을 저장하는 테이블이 전체 설명 텍스트를 저장하는 것보다 빠릅니까?

우리는 내가 일하는 곳에서 그것을 테스트했습니다. 우리는 조회 테이블을 다른 종류의 테이블과 구별하지 않았습니다. 그러나 귀하의 질문은 조회 테이블에 관한 것이 아니라는 점을 알려드립니다. 귀하의 질문은 서로 게이트 키 (ID 번호)에 관한 것입니다. ID 번호를 사용하지 않고 "조회"테이블을 만들 수 있습니다.

타이밍 예는 this SO question을 참조하십시오. 티핑 포인트가있는 것 같습니다. 티핑 포인트 아래에서 자연 키를 기반으로 한 쿼리는 대개 ID 번호를 기반으로하는 쿼리보다 빠르게 실행됩니다. (좁은 테이블과 더 적은 조인). 그러나 전환점을 지나면 대리 키가 자연 키보다 빠르게 실행됩니다.

그러나 "빠름"은 반드시 "빠름"을 의미하지는 않습니다. 그리고 "느린"속도는 아직 충분히 빠를 수도 있습니다.

+0

다른 링크를 제공해 주셔서 감사합니다. 그게 좋은 읽을 거리 였고, 플러스 구글에게 좋은 근거를 조금 더 많은 정보를 주었다. –