왜 모델입니까 .ForeignKey가 유리합니까?

Question

제 모델에는 Concert 클래스와 Venue 클래스가 있습니다. 각 공연장에는 여러 개의 콘서트가 있습니다. 나는 장소 개체의 기본 키를 포함 ... 간단한

venue = models.IntegerField(max_length = 10)

와 장소에 콘서트 클래스를 연결하고있다. 동료가 대신 venue = models.ForeignKey(Venue)을 사용할 것을 제안했습니다. 이것도 작동하는 동안, 내가 자리를 위해 모든 콘서트를 구문 분석 할 수 있었기 때문에 Concert.objects.filter(venue=4)의 Concert.objects.filter(venue=4)에서 ID 번호 ForeignKey : Venue_instance.Concert_set.all()과 같은 방식으로 사용할 수 있습니다. 내 방법을 사용하는 데 전혀 문제가 없었습니다.

IntegerField과 objects.filter()을 사용하는 방식은 ForeignKey과 마찬가지로 "ManyToOne"관계의 많은 부분을 차지하므로 잘못된 위치를 알고 싶습니다. ForeignKeys은 왜 유리한가요? 그들은 더 빠릅니까? 더 나은 데이터베이스 디자인입니까? 클리너 코드?

Answer 1

외래 키의 가장 실질적인 이점은 관계를 통해 자동으로 쿼리 할 수 ​​있다는 것입니다. Django는 자동으로 JOIN을 생성합니다.

자동 역관계 헬퍼는 언급 한대로 훌륭합니다.

다음은 정수 관계에서만 더 복잡한 몇 가지 예입니다. 다른 사람들이 지적했듯이

concerts = Concert.objects.filter(...) 

concerts.order_by('venue__attribute') # ordering beyond PK. 
concerts.filter(venue__name='foo') # filter by a value across the relationship 
concerts.values_list('venue__name') # get just venue names 
concerts.values('venue__city').annotate() # get unique values across the venue 

concerts.filter(venue__more__relationships='foo') 

Venue.objects.filter(concert__name='Coachella') # reverse lookups work too 

# with an integer field for Concert.venue, you'd have to do something like... 
Venue.objects.filter(id__in=Concert.objects.filter(name='Coachella')) 

... 데이터베이스 무결성 (물론 사용자 정의)를 모두 삭제, 유용하고, 마른 세수는 그냥 외래 키와 놀라 울 정도로 나에게 그 장고 관리자 및 양식 프레임 워크 작업을 발생했습니다.

class ConcertInline(admin.TabularInline): 
    model = Concert 

class VenueAdmin(admin.ModelAdmin): 
    inlines = [ConcertInline] 
    # that was quick! 

django 기능 외래 키를 처리하는 예제가 더 있습니다.

Answer 2

ForeignKey는 referential integrity을 적용하는 대부분의 데이터베이스에 구현 된 database concept입니다.

django는이 칼럼이 무엇을 참조하는지 알기 때문에 테이블 자체가 다른 테이블의 외래 키일 수 있으므로 SQL에서 해당 조인을 생성하는 관계를 연결하는 데 도움이 될 수 있습니다.

일반적인 단방향 체인 이외에 장고는 사용자가 인식 한 것처럼 매개 변수를 반대쪽에 추가합니다. 개최지 인스턴스가 있으면 venue.concert_set을 질의 할 수 있습니다.

• 당신은 참조 무결성 검사를하지 않습니다

  FK를 사용하여 정수를 사용하여 자신의 압연하지에 대해 가장 날 귀찮게 것은 때문이다.

• 당신은 SQL의 힘을 잃습니다. 당신이 참여할 수 없기 때문에, 당신의 모든 적당히 깊은 쿼리는 이제 데이터베이스에 여러 번의 조회가 필요할 것입니다. - 당신은 또한 프레임 워크가 SQL을 다루기 위해 제공하는 모든 레버를 잃는다.