이 질문에 대한 적절한 대답이있는 것 같습니다. 코드에서 자식 개체를 만들 때 부모 개체는 자식에 대한 참조를 저장합니다. 자녀는 참조를 저장할 구체적인 이유가없는 한 부모에 대해 알지 못합니다.데이터베이스의 상위 항목이 아닌 하위 항목에 외래 키가 저장되는 이유
데이터베이스에서는 반대가 표준입니다. 즉 : 당신은 "무언가가 많다"는 것을 만들어 내고, 많은 부모 항목에 대한 참조가 많은 자식 항목들 각각에 저장된다.
그래서 프로그래밍 중이라면 부모 항목에 저장된 하위 항목 목록이 있습니다. 데이터베이스를 사용하는 경우 부모 참조가있는 하위 항목이 많지만 부모에게는 하위 참조가 없습니다.
어떻게 그리고 왜 이렇게 되었습니까? 임의적 인 디자인 결정이 표준이되는 것일 뿐인가요? 아니면 데이터 저장소가 일방적으로 수행하는 성능이나 논리적인 이유가 있습니까?
확실한 이유가 있는지는 확실하지 않지만 제 의견은 여기 있습니다.
데이터베이스에서 각 셀은 하나의 데이터 조각 만 포함하도록 설계되었습니다. 아이는 PK를 통해 부모를 쉽게 참조 할 수 있으며 효과적으로 FK를 형성합니다. 그러나 부모가 자녀를 어떻게 참조합니까?
일대 다 관계에서 각 부모는 임의의 수의 하위 항목을 가질 수 있으므로 부모가 해당 참조를 보유해야하는 열의 종류는 무엇입니까? 자녀의 PK를 갖는 것은 쓸모가 없습니다. 왜냐하면 여러분은 칼럼 당 하나만 가질 수 있기 때문에 (그것은 일대일이 될 것입니다). 쉼표로 구분 된 문자열과 같은 해킹을 제외하고는 DB 셀에 PK 목록을 넣을 수는 없지만 FK의 목적을 무효화하고 RMDBS의 대부분의 이점을 제거합니다. 중간 테이블이 가능한 해결책이지만, 테이블을 자식이되고 다른 테이블에 참조가 없기 때문에 문제를 다른 장소로 옮기는 것입니다.
대조적으로 OOP 언어에는 컬렉션이라는 여러 속성을 하나의 속성에 저장하는 데 사용할 수있는 데이터 구조가 포함되어 있습니다. 이들을 사용하여 여러 개의 임의의 수의 하위 객체 참조를 포함하는 객체를 포함하는 속성을 가질 수 있습니다. 이러한 종류의 관계형 데이터베이스가 그러한 참조를 가능하게하지 못하는 구조입니까? 부모 개체 참조 (또는 다 대일)는 일반 개체 참조에서도 가능합니다.
이것은 많은 의미가 있습니다. 한 셀에 다양한 크기의 콜렉션이 있으면 대규모 검색이 악몽으로 변할 수 있음을 알 수 있습니다. 따라서 성능과 단순성을 위해 셀에는 하나의 데이터 항목이 있습니다. 결과적으로 참조가 많은 것은 어린이 또는 참조 용 테이블에 있어야합니다. – Rab
아이디어는 수정하지 않고 이전 것에 새로운 것을 추가 할 수있게하는 것입니다.
이름과 주소가있는 클라이언트가 있다고 가정하면 트랜잭션을 추가합니다. 트랜잭션은 클라이언트를 수정해서는 안됩니다. 그런 다음 클라이언트에 대한 특별 주문을 추가하는 식입니다. 이들 모두에 대해 클라이언트 테이블을 수정할 필요는 없습니다.
코드가 동일해야합니다. 이것은 커플 링/응집이라고하는 oop의 핵심 원칙입니다.
그럼 데이터베이스에 대한 이해가 시작됩니다. 감사. 하지만 클래스가 자식 객체에 대한 참조를 제공해서는 안된다는 말입니까?예 : 클래스 Person의 인스턴스는 Limb 참조가 없어야하지만 Class Limb의 인스턴스는 연결된 사람을 참조해야합니다. – Rab
Sql을 사용하면 모든 개체를 알고있는 일종의 글로벌 감독자와 사기를 맺을 수 있습니다. 사람은 아마도 사지와 상호 작용할 필요가있을 것이지만 거래는 고객에 대해 알 필요가 없을 수도 있습니다. 그것은 정말로 달려 있습니다. 최대한 관계를 최소화하십시오. – Eric
이론적으로 모든 자식 ID를 나열하는 필드에 배열 값을 만들 수는 있지만 매우 비효율적이며 SQL 기반 데이터베이스는 그렇게 작동하지 않습니다. – Logarr
@Logarr 나는 비슷하게 ... oop에서 자식 객체를 만들고이를 "맹인"부모에 대한 참조를 저장하여 어린이로 표시 할 수는 있지만 아무도 그렇게 생각하지 않는다. 새 데이터베이스?,)). 서로 인터페이스하는 프로그래밍의 두 영역이 왜 반대의 방식으로 구성되는지 궁금합니다. – Rab