열이 너무 많은 테이블에 냄새가 나는 이유는 무엇입니까?

Question

최근에 테이블에 너무 많은 열이 있거나 모델의 속성이 너무 많아 코드 냄새에 대해 다른 개발자와 논의한 적이 있습니다. 어떤 사람들은 너무 많은 애트리뷰트를 가진 모델이 너무 많은 일을하고 있으며 분할되어야한다고 주장한다. 그러나 실제로 모델에 이러한 속성이 필요한 경우 어떻게해야합니까?

users 테이블의 예를 들어 보겠습니다.

사용자는 등 first_name, last_name, street_name, city, state, age을 가질 수 있습니다. 인수에 따르면, street_name, city 및 state을 다른 테이블로 옮겨야한다고 가정합니다. 관련 데이터가이 방법으로 그룹화된다는 데 동의하지만 응용 프로그램이 자신의 주소를 사용하여 사용자를 쿼리하는 경우 2 테이블에 있기 때문에 더 비싼 작업이되지는 않습니까?

그래서 많은 특성을 가진 테이블을 모델링하는 올바른 방법은 무엇입니까? 은 (우리는 또한 이러한 경우를 고려해야합니다 1. 행의 수가 될 것 때 적은 행의 수는 거대 할 예정 2)이 꽤 격식을 중요시하는 질문

Answer 1

특히 address 시나리오를 사용하면 사용자 당 여러 개의 주소를 처리하거나 동일한 주소를 사용하여 여러 개의 등록을 추적/트랩하는 경우 매우 유용합니다.당신이 일반적인 description 필드와 주소의 특정 유형으로 행을 태그 type 열 (예를 들어 email, house, office, spouse 등)이 어디에

양자 택일로, 당신은 더 일반적인 주소 테이블 구현을 고려할 수 있습니다.

이야기의 도덕은이 이야기의 도덕적 인면이 하나 이상있을 수 있다면 별도의 테이블을 가질 수 있다는 것입니다. 정보에 대해 별도의 테이블 또는 두 개의 점프에서 아무런 혜택이 없을 때 정상화에서만 설정 동안 그 :

2. 한 번 또는
3. 모든 기본 키 개체 이상 발생하지 않습니다, 많은 변경하지 않습니다 그것을 가지고 있어야합니다.

Answer 2

. 데이터베이스 모델을 설계 할 때는 종종 성능을 염두에 두어야합니다. 테이블이 잘 보이기 때문에 테이블을 분할하지 않습니다. 당신이 중복

를 줄이거 나 동시성을 향상시킬 수 있습니다 때 예를

• 을 위해 그것을 할 것입니다.

모든 데이터베이스가 아닌 경우 최대 레코드 수의 한도가 있습니다. 따라서 데이터베이스를 효율적으로 저장할 수 있도록 테이블을 분할 할 수 있습니다.

클래스를 디자인 할 때 완전히 다릅니다. 클래스 분할은 성능에 큰 영향을 미치지 않지만 유지 관리에 큰 영향을 미칩니다. 유지 관리 가능성이 주요 관심사가되어야합니다.

Answer 3

"한 테이블에 너무 많은 속성"이있는 것은 아닙니다. 그것은 "하나의 테이블에서 잘못된 속성을 함께 묶는"문제입니다. 표의 핵심은 주제의 일부 엔티티 또는 관계와 관련되어야합니다. 키가 아닌 속성은 키, 전체 키 및 키 이외에 종속적이어야합니다 (결정된).

이것은 "데이터 정규화"를 간략하게 보여줍니다. 데이터 정규화는 데이터베이스의 여러 위치에 동일한 사실을 저장할 필요성을 방지합니다. 이 유해한 중복은 낭비 일뿐만 아니라 모순되는 데이터베이스로 이어질 수도 있습니다. 이것은 진짜 고통입니다.

정규화되지 않은 디자인을 정규화 된 디자인으로 변환 할 때 종종 테이블이 분할됩니다. 그러나 무작위로 테이블을 분할하지 마십시오. 정규화 규칙을 익히십시오. 당신이 그들을 무시할 때를 알만큼 충분히 전문가가 될 때까지 그들을 따르십시오.