빠른 액세스를 위해 정규화 된 데이터베이스 테이블을 분할 하시겠습니까?

Question

나는 모든 항목은 사람에 해당하고, ID는이 테이블의 열쇠는 database--에서 정규화 된 테이블이 여기에

(ID, name, age) 

말할 수 있습니다.

비 키 필드로 자주 액세스합니다.이 테이블은 이름 필드에서 한 번만 검색 할 수 있습니다.

그래서 이름 필드에 색인을 추가 할 수 있으므로이 필드에도 색인이 생성됩니다.

(ID, name) 
(ID, age) 

그는 빨리이 제안 :

CTO의이 표는 (이 경우 N = 2) 키가 아닌 필드 각각에 대해 하나 tables-- N으로 나누어되어야 함을 말한다 쿼리에 대한 액세스. 이와 같이 세분화 된 경우이 두 테이블 각각 은 ID를 키로 가지고 있으며 테이블은 다른 필드에서 인덱싱되지 않습니다. 심지어 속도가 느려집니다 access-- 내 의견을

이 빨리 제공하지 않습니다

• 인덱스 쿼리

• 에 추가로 테이블 액세스에 다시 전체 테이블을 검색하는 의미 일치하는 행이 발견되면 해당 행에서 두 테이블을 모두 가져 오는 것이 아니라 원본 테이블의 전체 행 (이름 & 세)을 가져 오십시오.

무엇이 누락 되었습니까?

TIA

Answer 1

당신의 논리는 절대적으로 정확하고 제안 된 솔루션은 어떤 혜택을 제공하지 않습니다, 심지어 정확히 설명하는 방법으로 문제를 악화시킨다.

자주 검색되는 필드에 인덱스를 추가하면 더 나은 결과를 얻을 수 있지만 검색 방법에 따라 실현 된 이점이 제한 될 수 있습니다. 예를 들어, 부분 일치 (name LIKE '%whatever%')를 검색하면 색인을 효과적으로 사용할 수 없습니다.

사용중인 데이터베이스에 따라 다른 기술을 사용하여 작업 속도를 높일 수도 있습니다. 메모리 캐싱, 전체 텍스트 인덱싱 등.

Answer 2

짧은 답변은 성능이 전반적으로 저하되고 나쁜 디자인이라는 것입니다. 그 외에도 필요에 따라 삭제할 수 없도록 (ID, 이름) 삭제하지 않고 (ID, 연령) 외래 키 제약 조건을 유지 관리해야합니다. 이러한 FK 제약 조건은 자체 오버 헤드를 추가합니다. 또는 FK를 구현하지 않을 수도 있지만 데이터 세트를 열어 필적 할 수없는 레코드가 될 수 있습니다. 이 시나리오는 함수를 작성하지 않는 일반적인 ORM 도구로 가능합니다. 반면에 함수를 사용하면 트랜잭션을 사용할 수 있고 함께 통과하거나 실패 할 수 있습니다. 이것은 쓰기에 대해서도 마찬가지입니다. 예를 들어 Mary Smith가 결혼하고 Mary White에게 이름이 바뀌면 어떻게 될까요? 그 위에 우리는 나이를 바꾸어야합니다. 이제 제안 된 디자인으로 더 복잡한 것을 추가하는 하나의 DB 트랜잭션에서 두 테이블을 모두 업데이트하는 것이 현명합니다

그런 다음 MySQL 유지 관리 문제가 있습니다.디자인에 필요한 것보다 많은 테이블을 추가하는 것은 유지 보수 작업을 방해하고 MySQL 자체 인덱스 유지 관리 오버 헤드에 더 많은로드를 추가합니다.

DB 성능이 저하되는 것 외에도 추가 된 쓸모없는 복잡성 때문에 개발자 생산성이 저하됩니다.

성능이 정말 큰 문제이고 데이터 세트가 실제로 너무 크고 빠른 텍스트 조회가 필요한 경우 스핑크스와 같은 기술을 사용하는 것이 더 좋고 널리 사용되는 기술입니다.

정직하게 말하자면, 그가 샤딩에 대해 읽은 것 같고 그가 읽었던 것을 완전히 오해 한 것 같습니다.