데이터베이스 스키마 질문

Question

지역 도시 페이지의 데이터 모델을 설계하고 있는데, 요구 사항과 비슷합니다.

그래서 4 개의 테이블 : 국가,시 /도, 이웃.

실제 생활 관계는 다음과 같습니다. 국가는 여러 이웃을 소유하고있는 여러 도시를 소유하고있는 여러 주를 소유하고 있습니다.

데이터 모델에서 : 우리는 FK와 동일한 방법으로 연결하거나 각각을 각각 연결합니까? 각 테이블과 마찬가지로 국가 ID, 주 ID, 도시 ID 및 NeighbourhoodID도있을 것입니다. 각 각에 연결되어 있습니까? 그 외의 다른 테이블 두 곳을 합치는 데 필요한 국가에서 이웃에 도착하는 것이 현명합니까?

등

Answer 1

업계 표준이 가장 가까운 것은 이것이다 나는 도시, 위도/경도의 IP의 빨간색 깜박임에 대한 유지하기 위해 필요 이상의 테이블이 있습니다 : 각 종속 테이블에 외래 키에 의해 연결되어가 즉각적인 부모 :

create table state 
(country_id number not null 
, state_id number not null 
, state_name varchar2(30) 
, constraint state_pk primary key (country_id, state_id) 
, constraint state_country_fk foreign key (country_id) 
     references country(country_id) 
) 
/
create table city 
(country_id number not null 
, state_id number not null 
, city_id number not null 
, city_name varchar2(30) 
, constraint city_pk primary key (country_id, state_id, city_id) 
, constraint city_state_fk foreign key (country_id, state_id) 
     references state(country_id, state_id) 
) 
/
create table neighbourhood 
(country_id number not null 
, state_id number not null 
, city_id number not null 
, neighbourhood_id number not null 
, neighbourhood_name varchar2(30) 
, constraint neighbourhood_pk primary key (country_id, state_id, city_id, neighbourhood_id) 
, constraint neighbourhood_city_fk foreign key (country_id, state_id, city_id) 
     references city(country_id, state_id, city_id) 
) 
/

:

create table country 
(country_id number not null 
, country_name varchar2(30) 
, constraint country_pk primary key (country_id) 
) 
/
create table state 
(state_id number not null 
, state_name varchar2(30) 
, country_id number not null 
, constraint state_pk primary key (state_id) 
, constraint state_country_fk foreign key (country_id) 
     references country(country_id) 
) 
/
create table city 
(city_id number not null 
, city_name varchar2(30) 
, state_id number not null 
, constraint city_pk primary key (city_id) 
, constraint city_state_fk foreign key (state_id) 
     references state(state_id) 
) 
/
create table neighbourhood 
(neighbourhood_id number not null 
, neighbourhood_name varchar2(30) 
, city_id number not null 
, constraint neighbourhood_pk primary key (neighbourhood_id) 
, constraint neighbourhood_city_fk foreign key (city_id) 
     references city(city_id) 
) 
/

크게 호의에서 떨어졌다 다른 방법은, 바로 위 부모 테이블의 키를 포함하여 복합 키와 자식 테이블의 기본 키를 정의하는 것입니다

이 접근법은 단기간에 대단히 다루기 힘든 조인을 생성하고 장기적으로 키가 변경 될 때 끔찍한 혼란을 야기하므로 더 이상 사용되지 않습니다. 기본 키는 변경되지 않아야하지만 키를 조합하면 의미가 생깁니다. 결과적으로 시스템의 데이터가 변경 될 때 - 예를 들어 주 경계 재구성 - 도시 전체가 변경되면 Neighborhood 테이블 및 다른 모든 하위 시스템과 연계되어야합니다. 왝.

create table state 
(state_id number not null 
, state_name varchar2(30) 
, country_id number not null 
, constraint state_pk primary key (state_id) 
, constraint state_country_fk foreign key (country_id) 
     references country(country_id) 
) 
/
create table city 
(city_id number not null 
, city_name varchar2(30) 
, country_id number not null 
, state_id number not null 
, constraint city_pk primary key (city_id) 
, constraint city_country_fk foreign key (country_id) 
     references country(country_id) 
, constraint city_state_fk foreign key (state_id) 
     references state(state_id) 
) 
/
create table neighbourhood 
(neighbourhood_id number not null 
, neighbourhood_name varchar2(30) 
, country_id number not null 
, state_id number not null 
, city_id number not null 
, constraint neighbourhood_pk primary key (neighbourhood_id) 
, constraint neighbourhood_country_fk foreign key (country_id) 
     references country(country_id) 
, constraint neighbourhood_state_fk foreign key (state_id) 
     references state(state_id) 
, constraint neighbourhood_city_fk foreign key (city_id) 
     references city(city_id) 
) 
/

그것은 복합 키를 방지하지만 여전히 데이터 문제를 계단식 것을 가지고

귀하의 제안이의 대체 버전입니다. 또한 존재하지 않는 관계에 대해 외래 키를 도입함으로써 관계형 관행을 위반합니다 (이웃과 국가간에 직접적인 관계가 없으며 중간 연결을 통해 암시됩니다).

더하기 측면에서, 이것은 주어진 국가에 대한 환경을 반환하려는 쿼리를 실행하는 데 매우 유용 할 수 있습니다. 나는 이것이 유용했던 한 시스템에서 작업했다. (사실 상속 된 복합 키를 사용했으나 원칙은 동일하다.) 그러나 이것은 매우 전문적인 데이터웨어 하우스 였고 심지어 실행 된 쿼리는 응용 프로그램이 아닌 관리/개발자 쿼리였습니다. 거대한 양의 데이터 (수백만 개의 이웃)를 다루지 않는 한, 몇 가지 조인을 건너 뛰는 것에서의 성능 향상은 이러한 추가 열을 관리하는 오버 헤드의 가치가 없다고 생각합니다.

즉, 첫 번째 방법을 사용하십시오. 깔끔하고 표준입니다.

편집

"국가는 모든 국가 상태를 가지고 있기 때문이다. 그런 다음 국가 직접 도시 로 연결됩니다 불구하고 선택해야합니다."

사실이면 모든 것이 변경됩니다.물론 STATE는 CITY의 식별 외래 키로 사용할 수 없습니다. 그래서 CITY는 COUNTRY를 대신 참조해야합니다. STATE는 CITY에서 선택적으로 조회 할 수 있습니다.

대부분의 국가에는 카운티 또는 부서와 같은 일부 하위 부문이 있다고 생각합니다. 리히텐슈 타인 (Lichtenstein)과 산 마리노 (San Marino)와 같은 마이크로 주자들조차도 시정촌을 가지고 있습니다 (모나코는 단지 하나뿐입니다). 아마도 바티칸 시국 만이 유일한 나라 일 것입니다. 따라서 하나 또는 두 개의 엣지 경우를 지원하도록 데이터 모델을 구조화할지 아니면 성좌와 같은 예외에 대해 인공적인 "상태"를 주입하여 데이터를 찌그러 뜨릴 지 여부를 신중하게 고려하십시오. 어떤 방법도 완전히 만족스럽지 않습니다.

"어쨌든 테이블 구조를 변경되도록하지 않도록 경우 모든 필드는 자동 완성 필드 것인가?"

아무런 차이가 없습니다.

"하지만 아는 사람, 몇 달 후 우리 는 이 너무 지역과 일치 국가를해야합니다 몇 가지 멋진 기능을 발견 할 수 있습니다."

예, 그렇지만 다시는 그렇지 않을 수도 있습니다. XP에는 YAGNI - You're aren't gonna need it이라는 강력한 원칙이 있습니다. 기본적으로 많은 일을하지 말고 도착하지 못할 수도있는 미래의 요구 사항을 고려하여 설계를 복잡하게 만듭니다.

도착한 경우 첫 번째 해결 방법은 STATE를 CITY의 참조로 사용하지 않는 경우 중간 표 (또는 표)를 통해 NEIGHBORHOOD 및 COUNTRY에 가입하는 것입니다. 그 쿼리의 성능이 Teh Suck 일 때만! 데이터 모델을 조정할 것을 고려하면 조정에 완강하게 저항 할 수 있습니다.