Kepiye cara select_related lan prefetch_related ngokaké N+1 problem?

Question

Accepted Answer

**N+1 query problem** minangka masalah performance paling umum ing Django ORM: ngakses obyek sing ana hubungane ing loop ngakaké query database kasépélé kanggo saben siji. **`select_related`** lan **`prefetch_related`** ngatasi masalah kasebut kanthi ngambil data sing ana hubungane kanthi efisien — karepake minangka tools optimasi sing penting.

## The N+1 problem

```python
# ❌ N+1 queries
books = Book.objects.all()              # 1 query: fetch all books
for book in books:
    print(book.author.name)             # +1 query PER book to fetch its author!
# 100 books → 1 + 100 = 101 queries (terrible performance)
```

Saben akses `book.author` nglakokake query database maneh sacara lazy. Karo 100 buku, kuwi 101 query — masalah performance sing parah lan tersembunyi sing asring mung katon nalika ana volume data nyata.

## select_related — kanggo ForeignKey / OneToOne (SQL JOIN)

```python
# ✅ ONE query with a JOIN
books = Book.objects.select_related("author").all()
for book in books:
    print(book.author.name)             # NO extra queries — author was JOINed in
# 100 books → 1 query total
```

`select_related` ngjalanake SQL **JOIN** kanggo ngambil obyek sing ana hubungane ing query *sing padha*. Gunakake kanggo **forward ForeignKey lan OneToOne** relationships (obyek sing ana hubungane siji), ing ngendi JOIN kuwi efisien.

## prefetch_related — kanggo ManyToMany / reverse FK (query kasépélé)

```python
# ✅ TWO queries total (not N+1)
authors = Author.objects.prefetch_related("books").all()
for author in authors:
    for book in author.books.all():     # NO extra queries — books were prefetched
        print(book.title)
# query 1: all authors; query 2: all their books → Django joins them in Python
```

`prefetch_related` ngjalanake **query kasépélé** kanggo obyek sing ana hubungane lan nggabungi ing Python. Gunakake kanggo **ManyToMany lan reverse ForeignKey** relationships (akeh obyek sing ana hubungane), ing ngendi JOIN bakal multiply baris kanthi ora efisien.

## Sing kudu digunakake

```text
select_related   → ForeignKey, OneToOne (forward, single object) → SQL JOIN, 1 query
prefetch_related → ManyToMany, reverse ForeignKey (many objects) → 2 queries, joined in Python
You can combine and chain them, and span relationships:
  Book.objects.select_related("author").prefetch_related("tags")
  Book.objects.select_related("author__publisher")   # multi-level
```

## Ndeteksi N+1 problems

```text
✓ Django Debug Toolbar — shows the query count per page (spot N+1 visually)
✓ django-silk, or logging queries (connection.queries) to count them
→ If a page runs hundreds of similar queries, you likely have an N+1.
```

## Mulané kuwi penting

N+1 query problem minangka **masalah performance paling umum lan bedhol ing aplikasi Django**, lan ngerti `select_related`/`prefetch_related` kudu dikuasai kanggo nulis kode sing perform.

Masalah kuwi bersifat tersembunyi amarga syntax ORM sing gampang sing ndadekake akses obyek sing ana hubungane dadi gampang (`book.author.name`) kanthi senyep ngakaké query database saben-saben — kode sing katon apik karo sawetara record bisa ketungkul drastis karo volume data nyata (100 record → 101 query), asring mung ketemu ing production duwur beban.

Ero loro tool kuwi minangka solusi standard lan penting: **`select_related`** nggunakake SQL JOIN kanggo ngambil forward ForeignKey/OneToOne relationships ing query siji, dene **`prefetch_related`** nggunakake query kasépélé (nggabungi ing Python) kanggo ManyToMany/reverse-ForeignKey relationships ing ngendi JOIN bakal ora efisien — lan ngerti **sing kudu digunakake kanggo relationship type apa** minangka skill kunci.

Nguasai loro tool kuwi ngubah ratusan query dadi siji utawa loro, asring ningkatake page performance kanthi signifikan.

Optimasi kuwi fundamental banget amarga ngenali N+1 problems (gunakake tools kaya Django Debug Toolbar kanggo ndeteksi query count sing keterlaluan) lan ngaplikasikake fix sing tepat minangka core competency sing mbedakake developers sing nulis Django code sing efisien karo sing aplikasine lambat nalika data berkembang.

Sah ugi sing paling sering ditest ing interview Django, persis amarga nggambarake ORM understanding sing praktis lan critical kanggo performance.