데이터베이스의 복잡한 일대다 관계를 피하기 위해 테이블의 필드에 외래 키가 없도록 데이터베이스를 설계했습니다. 그러나 관계는 setter 및 getter를 사용하여 수동으로 연결됩니다. 프로그램을 작성하고 함수를 구현하면 되지만, getter, setter를 많이 작성하는 것이 너무 고통스럽다는 것을 깨달았습니다. 아니면 처음부터 이렇게 설계하지 말았어야 했는지
巴扎黑2017-05-17 10:10:09
이 디자인은 매우 훌륭합니다. 데이터베이스 추상화 계층 또는 ROM이 부족합니다.
데이터베이스 이론에는 CAP이라는 개념이 있습니다.
CAP 이론은 Eric Brewer 교수가 제안한 분산 애플리케이션을 설계하고 배포할 때 세 가지 핵심 시스템 요구 사항이 있으며 이 세 가지 요구 사항 사이에는 특별한 관계가 있습니다. 세 가지 요구 사항은 다음과 같습니다.
C: 일관성
A: 가용성 가용성
P: 파티션 허용 파티션 내결함성
CAP 이론의 핵심은 다음과 같습니다. 분산 시스템이 일관성, 가용성 및 파티션 내결함성의 세 가지 요구 사항을 동시에 충족하는 것은 불가능하며 기껏해야 두 가지만 충족할 수 있습니다. 뭐 동시에#🎜 🎜#.
그리고 대부분의 nosql 데이터베이스는 C(일관성)를 타협합니다.그러므로 외래 키를 버리는 것이 현명합니다. 외래 키는 모든 데이터의 일관성을 유지하는 데 사용되지만, 데이터의 실시간 일관성이 전혀 필요하지 않은 경우가 많으므로
eventual Consistency만 확인하면 됩니다.
世界只因有你2017-05-17 10:10:09
첫째, 관계형 데이터베이스의 외래 키(여기서는 특별히 매핑 관계라고 함)는 여전히 매우 유용합니다.
두 번째, 외래 키(여기서는 특별히 외래 키 제약 조건이라고 함)가 존재해서는 안 됩니다.
曾经蜡笔没有小新2017-05-17 10:10:09
외래 키를 사용하는 애플리케이션이 점점 줄어들고 있습니다. 10년 전에는 그런 사람들이 꽤 많았어요. 주로 사업 독립성을 고려했기 때문입니다. 저는 비즈니스를 전적으로 애플리케이션 측면에 두고 데이터베이스는 지속성을 위해서만 사용하는 것을 좋아합니다.
10여년 전에 일부 프로젝트 데이터베이스 작업을 시작했을 때 데이터베이스도 비즈니스에 관여했지만 나중에는 유지 관리가 매우 고통스럽다는 것을 알게 되었습니다. 나중에 프로젝트 유지 관리 중에 모든 문제를 처리하기 위해 데이터베이스 전문가를 추가해야 했습니다. 이 문제는 프로젝트 요약에서도 제기되었습니다. 데이터베이스 전문가의 비용은 매우 높습니다.