일대일 테이블 관계를 사용하면 어떤 이점이 있습니까? (MySQL)

Question

단순히 하나의 테이블에 모든 데이터를 저장하는 것과는 대조적으로 일대일 테이블 관계를 사용하면 어떤 이점이 있습니까? 항상 일대 다, 다 대일 및 다 대다 관계를 이해하고 사용하지만 일대일 관계를 구현하는 것은 지루하고 불필요한 작업처럼 보입니다. 특히 이름 지정을 사용하는 경우 데이터베이스 테이블에 관련 객체 (php)를위한 규칙.

1 : 1 관계의 좋은 예를 제공 할 수있는 인터넷이나이 사이트에서 아무것도 찾을 수 없습니다. 처음에는 '사용자'를 프로필 페이지에 대한 '나에 대한'같은 공개 정보와 로그인/암호 등의 개인 정보가 포함 된 두 개의 테이블로 구분하는 것이 논리적 일 수 있다고 생각했습니다. 어쨌든 테이블에서 선택할 필드를 선택할 수있을 때 불필요한 JOINS를 사용하는 모든 문제를 해결할 수 있습니까? 사용자의 프로필 페이지를 표시하는 경우 분명히 id, username, email, aboutme 등을 선택하고 개인 정보가 들어있는 필드는 선택하지 않습니다.

실생활에서 일대일 관계의 예를 통해 나를 가르쳐 주려는 사람이 있습니까?

Answer 1

필자는 응용 프로그램 DB 구조에 영향을주지 않고 기존 응용 프로그램의 일부 기능을 확장하기 위해 일대일 관계를 사용했습니다. 이것은 기존 db 테이블을 확장하는 눈에 거슬리는 방법입니다.

일대일 관계를 사용하는 또 다른 이유는 클래스 테이블 상속을 구현하는 것입니다. 계층 구조의 각 클래스에는 테이블이 있고 개체에는 해당 테이블 클래스의 부모 클래스에 해당 행이 있습니다 테이블, 그의 조부모 클래스 테이블에 등등.

참조, 예를 들어, 교리 2 Class Table Inheritance Page

Answer 2

한 가지 가능한 정보는 정보의 일부가 선택 사항 일 때입니다. 이렇게하면 하나의 큰 테이블에 여러 개의 null 입력 가능 필드가있을 필요는 없지만 논리적으로 필수 테이블과 선택적 테이블로 분리 할 수 ​​있습니다.

다른 용도는 일부 데이터가 다른 테이블과 공유되는 경우입니다. 예를 들어 컴퓨터 부품을 판매하는 사이트가 있다고 가정 해 보겠습니다. 모든 구성 요소가 공유하는 세부 사항을 예를 들어 넣을 수 있습니다. "parts"테이블을 만들지 만, "motherboards", "cpus"등의 특성을 넣으십시오.이 테이블은 일대일 관계로 부품 테이블을 사용합니다.

Answer 3

데이터베이스 엔진은 필드의 하위 집합 만 읽는 경우에도 데이터를 가져 오기 위해 전체 행을 메모리로로드해야 할 수 있습니다. 행당 필드 수가 적을수록 페이지 당 더 많은 행을 의미하므로 디스크 액세스가 줄어 듭니다.

Answer 4

은 여기에 다른 사람들이 당신이 실제로 테이블을 수정하지 않고 기존의 테이블을 확장 할

• 더 게시 할 예정입니다 확신이 있습니다. 아마도 타사 공급 업체가 제공 한 것이므로 동일한 키를 공유하는 두 번째 테이블 만 있으면 확장자를 구분할 수 있습니다.
• 빈번하게 액세스되는 테이블에는 고정 너비 열과 그렇지 않은 가변 열이있을 수 있습니다. 이 경우 자주 사용하는 항목의 행 길이가 고정 된 테이블을 사용하는 것부터 다른 모든 것에 대한 보조 테이블을 사용하여 효율성을 높일 수 있습니다.

또한 데이터베이스를 정규화 할 때 3rd Normal Form (3NF)으로 말하면 실제로 키를 "알지 못하는"열을 가지고 있으며 별도의 테이블로 끌어 와야 할 수도 있습니다.

Answer 5

테이블 하나를 too many fields (96 필드!)으로 확장해야 할 때 "일대일 관계"를 사용했습니다. 그래서, 우리는 또 다른 테이블을 만들고 그 안에 모든 새로운 필드를 넣습니다.

어쨌든, 내가 좋아하는 접근 방법이다 : 당신의 예를 들어 구체적으로

Table_Base: 
    ID 
    MANDATORY_FIELD 
Table_Option: 
    ID 
    OPTIONAL_FIELD 

Answer 6

: 이 있기 때문에, 로그인 및 암호 정보와 같은 테이블에 저장된 이름과 주소 등의 사용자 정보를 원하지 않는다 로그인 정보 테이블이 아닌 사용자 정보 테이블에 대한 권한을 조직의 누군가에게 부여 할 수 있습니다.나는 "하나의 테이블을위한 너무 많은 분야"주제에 대해 다른 사람들과 동의하지 않습니다. 많은 필드가 있고 양식이나 보고서에이 필드가 모두 필요하지 않은 경우 SQL을 사용하여 필요한 필드 만 선택하거나보기를 사용하여 너무 많은 데이터를 얻지 않도록 할 수 있습니다.

Answer 7

OO에는 상속 권한이 있습니다. 따라서 부모 개체의 데이터를 포함하는 테이블과 자식에 대한 특정 필드가 포함 된 다른 테이블을 가질 수 있습니다.

Answer 8

가장 일반적인 이유는 관계가 아닌 의무가 될 수 있다는 것이다. 즉, 모든 기본 엔티티에 적용 가능한 속성 세트가 있지만 서브 세트에만 적용되는 일부 속성이 있습니다.

또 다른 타당한 이유는 액세스 권한을 제어하는 ​​것입니다. 애플리케이션 전반에 걸쳐 고객 테이블을 사용할 수 있으며 모든 고객이 비밀번호와 신용 카드를 사용할 수 있지만 가시성/업데이트 권한을 제한 할 수 있습니다.

Ignacio Vazquez-Abrams 대답에 대한 Marga Keuvelaar 님의 의견이 잘못되었습니다. 더 나은 DML/DDL을 사용하여 영향을 완화 할 수는 있지만 모든 경우에 영향을 줄 수는 없습니다. 그러나 데이터 모델의 투명성을 성능 이점과 비교하여 항상주의 깊게 고려해야합니다.

C. 이미 밝혔다 된 내용 외에도

Answer 9

,

일부 열은 다른 사람과는 다른 "보안 등급"요구 사항이있을 수 있습니다. 예 : 직원의 이름이 그의 급여보다 "조금 더 공개"될 수 있습니다. 이제는 열 수준 보안이 일반적으로 DBMS에 의해 시행되지는 않지만 테이블 수준 보안이 종종 있습니다.

별도의 테이블에서 급여를 선택하면 DBMS의 보안 기능을 사용하여 사용자의 보안 요구 사항을 구현할 수 있습니다. 언급되지 않은 내 경험을 바탕으로

Answer 10

한 가지 더 :

두 테이블로 분리 또한 모델 클래스를 만드는 데 도움이됩니다. Customers 테이블과 DriverLicense 테이블과 이들 사이에 일대일 관계가 있다고 가정 해 보겠습니다. 엔티티 프레임 워크를 사용하는 경우 응용 프로그램에 Customer 클래스와 DriverLicense라는 두 개의 모델 클래스가있을 수 있기 때문에 두 개의 별도 테이블이 있으면 더 좋을 것입니다. 이렇게하면 엔티티 프레임 워크가 나중에 기존 고객에게 새 드라이버 라이센스 정보를 추가하거나 삭제하고 업데이트하는 것을 매우 쉽게 만듭니다. 간단히 말해 웹 개발 측면을 고려해 볼 때, 두 가지 별개의 엔티티 인 경우 일대일 관계가 있더라도 자체 테이블을 가져야한다고 생각합니다.