제품에 대한 고객 문의를 저장하는 데이터베이스가 있습니다.데이터베이스 : 테이블을 항상 정규화하고 기본 키를 사용해야합니까?
조회 참조 (텍스트), 제품 번호 (int) 및 개정 번호 (int)는 함께 판매 및 고객 간의 단일 토론을 고유하게 식별합니다.
결과적으로 enq, pdt 및 rev 값이 결합 된 uqniuely idquified 단일 조회에 대한 특정 세부 사항에 대해 많은 테이블이 있습니다.
CREATE TABLE은 모든 필드에 대해 AUTO INCREMENT UNIQUE PRIMARY KEY를 사용하지 않습니다.
제 질문은이 데이터베이스 디자인을 사용할 수 있습니까? 테이블을 항상 정규화해야합니까?
고마워.
AUTOINCREMENT는 사용할 필요가 없지만 모든 테이블에는 PRIMARY KEY가 있어야합니다. 기본 키는 레코드를 고유하게 식별하는 여러 필드의 조합 일 수 있습니다.
문의 참조 (텍스트), 제품 번호 함께 단일 토론을 고유하게 식별합니다.
때때로 사람들은 성능상의 이유로 데이터베이스를 비정규 화합니다. select 쿼리가 삽입 및 업데이트보다 훨씬 자주 발생하고 조인해야하는 테이블의 수 때문에 관심있는 select 쿼리가 반환되기가 더딘 경우, 비정규 화를 고려하십시오.
느리게 실행되는 특정 쿼리를 제공하면 많은 구체적인 조언을 얻을 수 있습니다.
PRIMARY KEY (또는 UNIQUE 제약 조건)을 사용하면 먼저 이러한 값이 매우 고유한지 확인하고 두 번째로 지정된 쿼리에 대한 검색을 크게 향상시킵니다.
SELECT *
FROM enquiries
WHERE enq = 'enquiry'
AND pdt = 'product'
AND rev = 'revision'
가 단일 인덱스 추구에게에 완료됩니다
PRIMARY KEY는 (enq, pdt, rev) 통해 인덱스 및이 쿼리를 작성하는 것을 의미한다.
인덱스가 없으면이 쿼리는 전체 테이블을 검색해야하므로 중복되지 않을 것이라는 보장은 없습니다.
(아주 많이 삽입 된 로그 테이블과 같은) 매우 매우 특별한 조건을 제외하고 테이블에 항상 PRIMARY KEY이 있어야합니다.
다음 두 가지 질문이 있습니다. (1) 항상 자동 증가 키가 필요하지 않습니다. 데이터를 손쉽게 조작 할 수 있기 때문에 실용적입니다. 또한 중복이없는 것은 필수 사항이 아닙니다. (2) 정규화는 학교 숙제를 할 때 필수적이지만, 어려운 일이 발생하면 데이터 무결성을 위협하지 않으면 삶을 편하게하기 위해 깨뜨릴 수 있습니다.
개인적으로, 나는 항상 항상 정상화에 관해서는, 내가 하나가 정규화 된 테이블을 위해 노력한다고 생각
아무것도에 사용되는 자동 incrment 수있는 경우에도 모든 테이블에 기본 키의 일종을 가지고 있지만, 실제로 테이블 디자인이 좋지만 표준화되지 않은 많은 좋은 이유가 있습니다. 이것은 DB 디자인의 '이론'이 현실에 부합하는 곳입니다. 그러나 정규화가 무엇인지 알아 내고, 그것을 위해 노력하고, 규칙에서 벗어나는 좋은 이유가 있습니다 (규칙을 무시하거나 나쁜 것은 좋은 디자인 룰을 무시함).
나는이 떼에서 떼어 놓고 있습니다. 문의 사항 (텍스트), 제품 번호 (int) 및 개정 번호 (int)를 기본 키로 사용하지 마십시오. 조회 참조가 텍스트 유형이고 25 또는 50 또는 500 자의 문자를 의미 했습니까? 기본 키가 해당 필드에서 만들어진 경우 해당 테이블에 대해 생성 된 모든 인덱스에 추가되므로 내보기가 너무 넓습니다. 3 개 필드의 크기와 사용해야하는 테이블의 크기만큼 모든 인덱스 행의 크기를 늘립니다. 이 테이블의 외래 키는 세 개의 필드도 필요합니다.
세 개의 필드를 고유 색인으로 지정하십시오. 자동 증분 값을 기본 키로 설정하고 클러스터 된 인덱스로 만듭니다. 이 마스터 테이블로 다시 링크되는 테이블은 테이블 1에서 테이블 2로 데이터를 링크하기 위해 메모리 공간이 작습니다.
데이터가 수천 행 또는 50,000 또는 500,000에 불과한 경우 정규화 된 데이터는 문제가되지 않으며 정규화되었는지 여부는 중요하지 않습니다. 데이터가 사용 가능한 RAM 캐시보다 커지기 시작하면 문제가됩니다.
비즈니스 규칙을 수행하기 위해 응용 프로그램에 데이터를 표시하는보기를 설계하십시오. 저장할 저장 프로 시저를 디자인하여 저장하십시오. SLA에서 응답 시간을 충족하도록 테이블 구조를 설계하십시오. SLA를 충족시키기 위해 정규화 또는 비정규 화하거나 수정하거나 색인을 생성하거나 더 큰 서버를 확보해야하는 경우 비즈니스 규칙을 충족하는보기를 통해 항상 데이터를 제공하기 때문에 앱에서 알 수 없습니다.
표가 단순 또는 복합 기본 키를 가져야하는지 여부를 다루는 정규화 이론은 없습니다. 믿거 나 말거나, "기본 키"의 개념은 데이터의 관계형 모델의 구성 요소가 아닙니다.
그런데 테이블은 거의 항상 기본 키로 정의되어야합니다. 기본 키는 단일 열일 필요는 없으며 자동 증가로 채울 필요가 없습니다. 귀하의 경우에는 조사를 고유하게 식별하는 3 개의 열이 될 수 있습니다.
테이블에 선언 된 기본 키가 없으면 중복 행이 생길 수 있습니다. 중복 된 행이있는 테이블은 튜플 세트가 아니라 튜플 백을 나타냅니다. 세트 대신 가방을 다루는 경우, 관계형 모델에 의해 예측 된 결과는 적용 할 필요가 없습니다. 중복 행을 방지하는 것이 중요한 이유입니다.
대답에 추가하기 만하면 기본 키가 테이블의 모든 레코드를 고유하게 식별합니다. 기본 키가 없으면 2 개 (또는 그 이상)의 동일한 레코드로 끝날 수 있습니다. 이 시점에서 동일한 레코드 중에서 하나의 레코드를 업데이트하거나 삭제하는 것은 불가능합니다. –