Problemi i N+1 pyetjeve** është problemi më i zakonshëm i performancës në Django ORM: përpjekja për të hyrë në objektet e lidhur në një lak shkakton një pyetje të veçantë të bazës të dhënash për secilin. select_related dhe prefetch_related e zgjidhin atë duke marrë të dhënat e lidhura në mënyrë efikase — ato janë mjete optimizimi thelbësore.
books = Book.objects.()
book books:
(book.author.name)
Secilit book.author në hyrje i dërgon në mënyrë të vlerësuar bazën e të dhënave përsëri. Me 100 libra, këto janë 101 pyetje — një vrasës i rëndë dhe fshehesë performance që shpesh zbulohet vetëm nën vëllimet reale të të dhënave.
# ✅ 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 kryen një JOIN SQL për të marrë objektet e lidhur në të njëjtën pyetje. Përdoreni atë për marrëdhëniet ForeignKey përpara dhe OneToOne (objekt i lidhur i vetëm), ku një JOIN është efikas.
# ✅ 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 kryhen një pyetje të veçantë për objektet e lidhur dhe i bashkon ato në Python. Përdoreni atë për marrëdhëniet ManyToMany dhe reverse ForeignKey (shumë objekte të lidhur), ku një JOIN do të shumëzonte rreshtat në mënyrë joefekse.
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
✓ 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.
Problemi i N+1 pyetjeve është problemi i vetëm më i zakonshëm dhe me ndikim më të madh në aplikacionet Django, dhe kuptimi i select_related/prefetch_related është thelbësor për të shkruar kod të performancës.
Problemi është i dhimbshëm sepse sintaksa e përshtatshme e ORM që bën hyrjen në objektet e lidhur kaq të lehtë (book.author.name) heshtazi shkakton një pyetje të bazës të dhënash sa herë që ndodh — kodi që funksionon mirë me disa regjistrime përkeqësohet katastrofalisht me vëllime të vërteta të të dhënave (100 regjistrime → 101 pyetje), shpesh zbulohet vetëm në prodhim nën ngarkesë.
Këto dy mjete janë zgjidhja standarde, thelbësore: select_related përdor një JOIN SQL për të marrë marrëdhëniet përpara ForeignKey/OneToOne në një pyetje të vetme, ndërsa prefetch_related përdor një pyetje të veçantë (bashkuar në Python) për marrëdhëniet ManyToMany/reverse-ForeignKey ku një JOIN do të ishte joefekse — dhe dijenia se cila të përdoret për cilin lloj marrëdhënieje është aftësia kyçe.
Zotërimi i tyre shndërron qindra pyetje në një ose dy, shpesh duke përmirësuar performancën e faqes në mënyrë dramatike.
Ky optimizim është kaq themelor sa që njohja e problemeve N+1 (përdorimi i mjeteve si Django Debug Toolbar për të lokalizuar numrin e tepërt të pyetjeve) dhe zbatimi i zgjidhjes së duhur është një kompetencë bazë që dallon zhvilluesit që shkruajnë kod Django të performancës nga ata aplikacionet e të cilëve ngadalësohen ndërsa rriten të dhënat.
It's also among the most frequently-tested Django interview topics, precisely because it reflects practical, performance-critical ORM understanding.