Zum Hauptinhalt springen

Search & Filter

Wie SpeamCore Suche umsetzt — was funktioniert global vs. modul-spezifisch, wie performant ist das bei 100k+ Datensätzen.

Such-Ebenen​

Globale Suche​

Erreichbar über: ⌘+F (Mac) / Ctrl+F (Windows) oder Sidebar-Such-Icon.

Was wird durchsucht?​

  • Kunden-Namen, Adressen, USt-IdNr
  • Lieferanten analog
  • Produkt-Bezeichnungen
  • Beleg-Nummern (Rechnungen, Aufträge)
  • Mitarbeiter-Namen
  • Kommentar-Felder (eingeschränkt — DSGVO)

Such-Algorithmus​

  • Tippfehler-tolerant (Levenshtein-Distance)
  • Teilwort-Match („Mu" findet „Müller", „Musterm")
  • Mehrere Wörter AND-verknüpft
  • Anführungszeichen für exakte Phrasen
  • Modul-Prefix möglich („customer:Beispiel" sucht nur Kunden)

Modul-Suche​

Pro Modul-Liste oben rechts ein Such-Feld:

  • Schnellsuche über die wichtigsten Spalten (Name, Nummer, ID)
  • Live-Update — beim Tippen Filterung
  • Reset über X-Button

Filter​

Standard-Filter (UI)​

Toolbar-Button Filter öffnet Filter-Bereich. Pro Spalte:

  • Text: contains / equals / starts with
  • Datum: gestern / letzte Woche / Datum-Range
  • Auswahl: Multi-Select aus Stamm-Werten
  • Zahlen: gte / lte / Range

Filter-Vorlagen​

  • Sachbearbeiter kann Filter speichern als „Meine Woche", „Top-Kunden"
  • Vorlagen sind nutzer-spezifisch
  • Ein-Klick-Anwendung später

Erweiterte Filter (POST-API)​

Über API mit komplexen Bedingungen:

{
  "filter": {
    "AND": [
      { "status": "active" },
      { "OR": [
          { "name": { "contains": "Müller" } },
          { "ustId": "DE123" }
        ]
      }
    ]
  }
}

Mehr in API CRUD-Patterns.

Performance-Tricks​

Bei vielen Datensätzen (>10k)​

  • Filter setzen vor offener Liste — Initial-Filter „nur Aktive"
  • Pagination klein halten — 50-100 pro Page, nicht 500
  • Sortierung indexiert — bei Custom-Sort Performance-Degradation möglich
  • Bulk-Aktionen statt Schleife (siehe Tipps & Tricks)

Bei Datensätzen mit vielen Sub-Daten​

  • Sparse Fieldsets über ?fields=id,name (API)
  • Include sparsam — ?include=locations ist teuer
  • Cursor-basierte Pagination für sehr lange Listen

Indexierung im Hintergrund​

Bestimmte Felder sind DB-indexiert für schnelle Suche:

  • customers.name, customers.number, customers.ustId
  • salesDocuments.number, salesDocuments.customerId
  • workorders.number, workorders.employeeId
  • alle Datums-Felder mit Standard-Filter
  • alle Status-Felder

Cross-Modul-Suche basiert auf einem Such-Index der nachts neu gebaut wird (für nicht-indexierte Felder wie Kommentare).

Such-Anti-Patterns​

  • ❌ Wildcard am Anfang — „%Müller" ist langsam, ohne Index
  • ❌ Volltext in Kommentaren alle Beleg-Felder durchsuchen — nur relevante
  • ❌ Zu kurze Such-Strings — „a" liefert Tausende Treffer
  • ❌ Komplexe Conditions ohne Indizes

DSGVO-Aspekte​

  • Personal-Daten-Suche wird im Audit-Log protokolliert (wer hat nach welchem MA gesucht)
  • Bei Auskunfts-Anfrage alle Such-Treffer + Inhalte exportieren
  • Bei Löschung wird Such-Index entsprechend bereinigt

KI-Chat als alternative Suche​

Statt Filter zu konfigurieren, im KI-Chat fragen:

Welche Kunden haben offene Posten >30 Tage in Stuttgart?

KI baut die Filter automatisch und zeigt Resultate. Schneller als Filter-UI bei komplexen Fragen.

Verwandte Doku​