문제

대본

3 개의 데이터베이스 테이블이 있습니다. 하나는 이미지이고 다른 하나는 사람과 장소입니다. 각 사람은 많은 이미지를 가질 수 있고 각 장소에는 많은 이미지가있을 수 있으므로 사람과 이미지 모두뿐만 아니라 장소와 이미지 사이의 하나에서 많은 관계를 갖기를 원합니다.

의문

외국 키를 기본 키와 같은 이름으로 불려야합니까? 아니면 이미지 테이블의 외국 키를 "pktableId"와 같은 일반적인 것으로 호출 할 수 있습니까? 이렇게하면 이미지 테이블이 하나만 필요합니다.

대단히 감사합니다.

문안 인사,

편집하다:

단일 이미지 테이블 만 갖고 싶어하는 이유는 각 이미지가 단일 다른 테이블 만 참조하기 때문입니다. 이뿐만 아니라 여기에 두 개의 테이블의 예제를 사용했습니다. 실제로 사용하는 데이터베이스는 20 개의 테이블이 있으므로 20 개의 일대일 관계에 단일 이미지 테이블을 사용할 수 있는지 여부를 알고 싶었습니다. ?

도움이 되었습니까?

해결책

편집하다

하나의 이미지가 20 개의 테이블 중 하나에 의해서만 소유되면이 디자인은 다음과 같습니다.

People (PersonId, Name)
Places (PlaceId, Name)
Dogs (DogId, Breed)
Doors (DoorId, Height, Width)
Images (ImageId, ImageBinary, OwnerId, OwnerTable)

소유자가 속한 테이블의 이름 또는 코드는 소유자입니다.

이렇게하면 이미지 테이블에 20 fks 또는 20 개의 연관성 테이블이 절약됩니다. 그런 다음 조인에서 합류하는 테이블에 따라 소유권을 지정합니다.

ID (예 : tinyint, smallint 및 int), 바람직하게는 모두 (예 : int)에 변환 가능한 유형을 사용해야하며, 트리거 또는 다른 코드를 통해 참조 무결성을 직접 관리해야합니다.

/편집하다

3이 아닌 5 개의 테이블이 필요합니다.

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary)
ImagesPeople (ImageId, PersonId)
ImagesPlaces (ImageId, PlaceId)

원하는대로 필드를 호출 할 수 있습니다. people.id, imagespeople.personid 등

그러나 당신이 할 수없는 것은 다음과 같습니다.

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary, PlaceOrPersonId)

글쎄, 당신은 할 수 있지만, 데이터베이스는 당신이 관계를 시행하거나 FK가 속한 테이블을 알려주는 데 도움이되지 않습니다. 당신은 어떻게 알겠습니까? ID 증분을 비틀기, 이미지에 유형 열을 추가하거나 Guids를 사용하는 것과 같은 해킹 작업이 있습니다.

대안으로 :

Things (ThingId PK, Type)
People (ThingId PK/FK, Name, Age)
Places (ThingId PK/FK, Name, LatLon)
Images (ImageId PK, ImageBinary, ThingId FK)

이미지를 "사물"으로 만들 수도 있습니다. 때때로 당신은 이와 같은 디자인을 볼 수 있습니다. 그것은 당신에게 참조 무결성을 제공하지만 유형 독점 성은 아닙니다. 사람, 장소 및 이미지에서 똑같은 일을 할 수 있으며 데이터베이스는 신경 쓰지 않을 것입니다. 당신은 그 규칙을 스스로 코딩해야 할 것입니다.

편집 : Cylon Cat의 제안에서 시나리오 4 :

People (PersonId, Name)
Places (PlaceId, Name)
PeopleImages (PeopleImageId, ImageBinary)
PlaceImages (PlaceImageId, ImageBinary)

여기에서 이미지는 한 사람이나 장소가 독점적으로 소유합니다. 버전 2와 유사하지만 선언 된 외래 키가 있습니다. 더 적은 조인이 필요하기 때문에 5 개의 테이블 설계 대 성능 혜택이있을 수 있습니다. "이미지"를 "PeopleImage"및 "PlaceImage"로 대체하는 독특한 실체로서 "이미지"를 잃습니다.

다른 팁

Peter가 지적했듯이, 당신은 정말로 많은 관계가 필요합니다. 한 사람만으로도 이미지를 그림으로 제한하지 않는 한, 좋은 장소 색인은 장소 이름의 계층 적 특성 (Montmartre, Paris, France = Three Pabily)을 반영합니다. 한 곳의 이름).

이제 기술적으로 인덱스와 테이블을 호출 할 수 있으며 예약 된 단어가 아니며 이미 사용되지 않은 모든 것을 호출 할 수 있으며, X, Y, Z12345 및 Wobbly는 모두 색인의 유효한 이름입니다.

그러나 실제로 저장된 내용과 무엇을위한 이름을 지적하는 이름 지정 컨벤션을 따르는 것이 가장 좋습니다. 따라서 people_x_images와 places_x_images 테이블은 귀하의 경우 좋은 생각입니다. 실제 이미지 테이블의 사람이나 장소에 대해 실제로 아무것도 필요하지 않습니다. 마찬가지로 사람과 장소 테이블의 이미지에 대해 아무것도 필요하지 않습니다.

이론적으로 이미지 테이블에 두 개의 외국 키를 추가 할 수 있습니다. 그런 다음 쿼리를 실행할 때 NULLS를 허용하고 적절한 열에 가입 할 수 있습니다. 이 테이블은 14 개의 테이블을 사용해야 할 때 어떤 모습이 있습니까?

만약 당신이 안내를 사용하지 않으려면, 나는 당신이 그것을 이해해야하는 다음 사람을 위해 그것을 많이 설정했다고 말합니다.

하나의 테이블을 사용할 수 있지만 관계에는 20 개의 다른 필드가 필요합니다. 외국 키 관계를 설정하면 모든 데이터가 상위 테이블과 관련되어야하며 두 개의 외국 키 관계를 한 테이블에 저장할 수 없습니다. 따라서 원하는 각 FK에 대해 열을 설정해야합니다.

어때

Person (PersonId PK, Name, ImageId FK)
Image (ImageId PK, Name)
Place (PlaceId PK, Name, ImageId FK)
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top