룩업 테이블이 너무 많습니다.

Question

데이터베이스에 룩업 테이블이 너무 많아서 어떤 부작용이 있습니까?

응용 프로그램을 기반으로 너무 많은 열거 형을 내포해야합니다.

전문가의 조언은 무엇입니까?

Answer 1

처음에 "얼마나 많은 것이 너무 많습니까?"라고 물어보십시오. 두 테이블 사이에 논리적 관계가있는 경우 FK가 있어야합니다.

데이터베이스의 모든 위치에서 관련 테이블이 필요하지 않은 경우 해당 테이블을 제거하고 "IN"절이있는 CHECK 제약 조건을 사용하여 데이터 유효성을 적용하는 방법을 고려할 수 있습니다. 그러나이 경우 열거 형 내의 각 새 값으로 테이블이 변경됩니다.

개인적인 조언은 FK와 테이블을 유지하는 것입니다. 그것은 명확한 해결책이고 데이터베이스는 숫자에 대한 설명 텍스트가 있으면 유지 보수하는 것이 좋습니다.

Answer 2

조회 데이터의 전체 요점은 특정 필드에 유효한 식별자의 유한 목록이 있다는 것입니다. 이러한 특정 필드가 프로 시저 또는 where 문에서 올바른 프로세스 경로를 결정하거나 select 목록을 제한하는 데 사용되는 경우에는 너무 많은 조회와 같은 것이 없습니다.

특정 프로세스 또는 where 절에 대한 식별자의 유한 목록이 아닌 경우 조회 값이 아니어야합니다.

조회 값으로 간주 될 수 있지만 꼭 그래야 할 필요는없는 두 가지 필드가 마음에 듭니다.

도시 및 지방/주 :

가 이들의 유한 목록입니다하지만 sooo를 많이 있기 때문에 당신은이에 대한 조회를 만들고 싶어하지 않을 수 있습니다.

Answer 3

플로리안으로서, 나는 체크 인 (..)을하는 데 더 많은 외래 키를 갖고 싶어합니다. 간단한 이유 때문에 : 테이블에 다른 레코드를 삽입 할 수 있습니다.

Maintaning CHECK IN()은 훨씬 더 큰 문제입니다. 이 시나리오를 상상해보십시오 :

CREATE TABLE street 
(
    id serial not null, 
    st_type varchar(20) not null, 
    st_name varchar(100) not null, 
    constraint street_pk primary key (id) 
    constraint street_type_check check st_type in ('STREET','AVENUE','SQUARE') 
); 

이러한 유형의 행을 선택 했습니까? 다른 것을 추가해야하는 경우, 제한 조건을 제거하고 다시 작성해야합니다.

SQUARE와 같은 목록에서 항목을 지우는 경우 해당 유형의 이미 커밋 된 행 (삽입시 확인 됨)은 어떻게됩니까? 그들은 여전히 ​​잘못된 유형을 유지합니다.

테이블 및 외래 키를 유지 관리하고 추적하기가 더 쉽습니다.

Answer 4

조회 테이블이 너무 적다는 것이 얼마나 끔찍한 것인지 말해 보겠습니다. 내가 일한 한 곳의 원래 설계자는 모든 조회를 하나의 테이블에 넣고 typeid를 사용하여 조회가 무엇인지 정의하기로 결정했습니다. 이로 인해 거의 모든 쿼리가이 테이블에 도달하여 성능에 걸림을 초래하는 설명 설명 값을 가져 왔습니다.

외래 키는 청크가 아닌 전체 테이블에만있을 수 있기 때문에 별도의 조회가 없으면 typeid를 사용하는 필드는 해당 필드에 적절한 값으로 제한되지 않습니다. 따라서 clientid를 저장 한 파일에 실수로 사용자 그룹의 값이 포함될 수 있습니다.이로 인해 데이터 무결성 문제가 발생하고 컨텍스트에서 의미가없는 값을 해석해야 할 때보고가 훨씬 어려워졌습니다. 테이블을 너무 적게 사용하는 것은 상을 줄 수 없으며 사실 데이터베이스 설계에서 종종 반 패턴입니다.

필요한 경우 1000 개의 조회 테이블을 만듭니다.