PostgreSQL의 외부 키 사용 허용 위치 정보

개시하다

안녕하세요, 저는 클라우드를 개발하고 관리하는 저널 엔지니어입니다.
회사 전체 인원이 각양각색의 활동 달력을 방해했다.
이번에는 PostgreSQL의 Advent Calendar 2021의 보도로 나왔다.

PostgreSQL의 외부 키 사용 허용 위치 정보

먼저 당사의 로그에는 널을 허용하는 외부 키가 자주 사용됩니다.
사용하는 곳은 기본적으로 0.1대 0.N의 관계성일 때

고양이는 들고양이가 있기 때문에 때때로 주인이 없다.이 경우 고양이는 주인의 ID가 없다.
주인은 고양이를 여러 마리 키울 수 있다.아직 고양이를 기르는 사육사가 없다.
이때cats 책상 창id(사육자 ID)를 null lble로 바꾸면 사육자가 없는 고양이(들고양이)를 표현할 수 있다.
이 경우 테이블은 빈 외부 키를 사용하지 않거나 중간 테이블을 사용할 수 있습니다.

이는 널이 정규화하지 않은 교과서 모델이라고 할 수 있다.

허용된 외부 키워드의 ISNULL 검색 및 ISNOT NULL 검색

간단한 질문으로 ISNULL 및 ISNOT NULL 검색을 인덱스로 수행할 수 있는 외부 키워드 모드가 허용됩니까?
대답은 YES다.
https://www.postgresql.jp/document/13/html/indexes-ordering.html
기본적으로 B-tree 인덱스는 항목을 오름차순으로 저장하고 NULL은 저장합니다.
따라서 B-tree 색인에서 마지막 NULL이 저장되고 색인을 사용하여 ISNULL 검색, ISNOT NULL 검색 등이 가능합니다.
따라서 이번 예에서 널은 외부 키워드 모드에서 주인이 있는 고양이나 주인이 없는 고양이를 참고하면 색인을 이용할 수 있다.
IS NULL 검색의 경우 null 값이 적으면 색인 일부를 더하면 속도가 빨라집니다.
'SQL 고속화 in PostgreSQL'이라는 책의'2.1 삭제 표시가 있는 데이터 신속 배제'섹션에서는 null의 값이 압도적으로 적거나 많은 경우에만 null이 아닌 값을 조건으로 하는 부분 색인을 추가하는 것을 권장한다.

create index cats_owner_id_idx
  on cats(owner_id)
  where owner_id is not null;

https://booth.pm/ja/items/502116
왜 이렇게 빨라요? 인덱스 크기가null의 값을 줄여서 메모리에 넣기 쉬워요.
한편, 중간 테이블 모드에서 주인이 없는 고양이나 주인이 있는 고양이를 검색할 때 중간 테이블을 연결하는 경우가 있어 비용이 들 수 있다.

도대체 뭐가 좋아요?

SQL에서 대부분의 경우 테이블의 결합은 매우 무거운 처리이기 때문에 필자는 많은 상황에서 널이 외부 버튼 모드를 허용하는 성능이 더욱 좋을 것이라고 생각한다.(물론 앞에서 말한 바와 같이 이것은 사례이다.)
또 테이블을 중간에 끼우면 SQL과 OR 맵의 코드가 다소 복잡해지기 때문에 추천하지 않는다.
누엘을 넣는 게 좋지 않다는 의견도 있지만 누엘을 허용하는 외부 열쇠를 사용하는 건 어때요?