# ADR 001: Datenbank-Indexstrategie für Such- und Listenperformance

## Status

Entwurf

## Problem

Mit wachsender Datenmenge drohen langsame Listen-/Filterabfragen für Requests, Offers und Reviews. Die aktuelle Datenbankstruktur benötigt eine gezielte Indexstrategie zur Optimierung der Performance.

## Lösung

Implementierung einer gezielten Indexstrategie für kritische Abfragepfade in den Datenbanktabellen.

## Kritische Query-Pfade

### 1. Help Requests Feed
- Abfragen von Requests mit Filter nach Status, Erstellungsdatum, Requester-ID
- Beispielabfragen:
  ```sql
  SELECT * FROM help_requests WHERE status = 'open' ORDER BY created_at DESC LIMIT 20;
  SELECT * FROM help_requests WHERE requester_id = ? ORDER BY created_at DESC;
  ```

### 2. Offers Historie
- Abfragen von Offers zu bestimmten Requests oder von bestimmten Helfern
- Beispielabfragen:
  ```sql
  SELECT * FROM offers WHERE request_id = ? ORDER BY created_at DESC;
  SELECT * FROM offers WHERE helper_id = ? ORDER BY created_at DESC;
  ```

### 3. Reviews
- Abfragen von Reviews zu Deals, Benutzern oder Bewertungen
- Beispielabfragen:
  ```sql
  SELECT * FROM reviews WHERE deal_id = ?;
  SELECT * FROM reviews WHERE reviewer_id = ?;
  SELECT * FROM reviews WHERE reviewee_id = ?;
  ```

## Empfohlene Indexe

### help_requests Tabelle
1. `idx_status_created_at` (status, created_at)
2. `idx_requester_id` (requester_id)

### offers Tabelle
1. `idx_request_id_created_at` (request_id, created_at DESC)
2. `idx_helper_id_created_at` (helper_id, created_at DESC)

### reviews Tabelle
1. `idx_deal_id` (deal_id)
2. `idx_reviewer_id` (reviewer_id)
3. `idx_reviewee_id` (reviewee_id)

## Performance-Kriterien

- Jede kritische Abfrage hat eine begründete Index-Empfehlung
- Performance-Regressionsrisiko für Listenansichten sinkt nachvollziehbar
- EXPLAIN-basierte Erfolgskriterien für jede Kernabfrage festgelegt

## Implementation

Die Indexe werden in separaten Migrationen implementiert, um die Performance der bestehenden Datenbankoperationen nicht zu beeinträchtigen.