예상로드가 연간 200 만 행 인 제출 된 애플리케이션 양식의 데이터가 포함 된 데이터베이스 테이블이 있습니다.별도 테이블의 Nullable 데이터베이스 특성
응용 프로그램에 사용자 지정 텍스트를 태그하는 옵션이 있지만이 기능은 아마 5 ~ 10 % 만 사용됩니다. 나중에이 텍스트로 양식을 검색 할 수 있습니다.
기본 테이블에 nullable 특성으로 구현해야합니까, 아니면 이것을 키와 텍스트 만 포함하는 별도의 테이블로 추출하는 것이 더 좋습니까?
별도의 테이블에 널 (NULL) 텍스트 열을 갖는 것은이 null 허용되지 않습니다) 여러 가지
1 나을 다시 것 가입
3) 당신이 부모 테이블의 PK에 합류 할 때 비효율적이지는 않을 것이며 모든 확률로 해시 합을 사용할 것입니다.
4) 이후에 각 응용 프로그램에서 이러한 선택적 열을 더 많이 사용하기로 결정하면 확장 가능할 것입니다. (... 응용 프로그램 번호, 날짜)
응용 프로그램
답변은 아마도 사용할 특정 DBMS에 따라 달라질 수 있습니다. 예를 들어, null 텍스트 컬럼이 DBMS에서 차지하는 공간은 얼마나됩니까? 또한이 텍스트 열은 얼마나 큰가? - 단지 몇 자 또는 잠재적으로 수천입니까?
텍스트에 대해 별도의 테이블을 가질 수 있다는 장점 중 하나는 전체 테이블 스캔이 필요한 경우 텍스트 기반의 검색이 더 효율적일 수 있다는 것입니다. 행이 있으며이 행은 단일 테이블에있는 행보다 작습니다. 그러나 다른 데이터를 얻으려면 주 테이블에 다시 조인해야한다는 사실과 균형을 이루어야합니다.
유일한 방법은 두 가지 방법으로 설정하고 벤치마킹하는 것입니다. 별도의 테이블
2)는 의미 상 더 우아한로 이동 한 경우
고유 한 테이블의 가치가없는 컬럼의 전형적인 예는 Middle_Initial char (1)입니다. –
"더 나은"
Application_Attachments (응용 프로그램 #, text_col1을) : 다음과 유사한 디자인을 볼 수 있을까? 최적화하려는 것을 제공 할 수 있습니까? "더 나은"것은 모호합니다. 뭐든지 "더 좋을"수 있습니다. 너에게 중요한 것은 무엇인가? –
글쎄, 두 테이블은 복잡해 보이지만 널 값으로 행의 90 %를 피하는 중복성은 적습니다. 그리고이 텍스트들을 검색하는 것은 별개의 테이블에 배치 될 때 더 쉬울 것입니다. 그러나 다시 주 테이블에 nullable 특성을 두는 것이 더 단순 해 보이지만 빈약 한 데이터베이스 설계로 간주 될 수 있습니다. – lox