Best Practices und häufige Stolperfallen

Lerne, wie Ninox Lese- und Schreibtransaktionen ausführt und wie du typische Performance-Probleme in Skripten vermeidest.

Gute Ninox Logik macht mehr, als nur das richtige Ergebnis zurückzugeben. Sie sollte auch vorhersehbar laufen, andere Nutzer nicht blockieren und leicht wartbar bleiben.

Transaktionen in Ninox verstehen

Ninox führt Datenbankaktionen als Transaktionen aus. Eine Transaktion fasst einen oder mehrere Vorgänge zu einem Ausführungsschritt zusammen.

In der Praxis bedeutet das, dass Ninox das Lesen und Ändern von Daten unterschiedlich behandelt.

Lesetransaktionen

Eine Lesetransaktion fragt Daten ab, ohne sie zu ändern.

Typische Beispiele sind:

• Datensätze in einer Tabelle filtern

• eine Abfrage ausführen, um passende Datensätze zu finden

• Werte lesen, um sie in der App anzuzeigen

Wenn Ninox eine Lesetransaktion startet, arbeitet es mit dem Datenstand, der in diesem Moment aktuell war. Änderungen, die andere Nutzer während derselben Abfrage speichern, sind nicht Teil dieses Ergebnisses.

Ninox kann viele Lesetransaktionen gleichzeitig verarbeiten. Ein Nutzer, der Daten liest, blockiert normalerweise keinen anderen Nutzer beim Lesen.

Schreibtransaktionen

Eine Schreibtransaktion ändert Daten.

Typische Beispiele sind:

• einen Datensatz erstellen

• einen Feldwert bearbeiten

• einen Datensatz löschen

• auf einen Button klicken, der Daten aktualisiert

• Logik ausführen, die Werte zurück in die Datenbank schreibt

Es läuft immer nur eine Schreibtransaktion gleichzeitig. Andere Schreibtransaktionen warten, bis die aktuelle beendet ist.

Das ist meist kein Problem. Die meisten Schreibtransaktionen sind sehr schnell abgeschlossen.

Automatisierungen wie On create und On update laufen innerhalb derselben Schreibtransaktion, die sie ausgelöst hat.

Ausführung auf Client und Server

Ninox kann Logik auf dem Client oder auf dem Server ausführen.

Der Client ist die App, die auf dem Gerät eines Nutzers läuft. Der Server verarbeitet gemeinsam genutzte Datenbankoperationen im Hintergrund.

Wo Logik läuft, hängt davon ab, was die Aktion tun muss. Für die meisten Nutzer ist dieser Punkt entscheidend:

• Leseoperationen sind meist leichtgewichtig.

• Schreiboperationen müssen warten, bis sie an der Reihe sind.

• Lange Schreiboperationen können andere Schreibaktionen verlangsamen.

Warum Ninox langsam wirken kann

Wenn Ninox langsam wirkt oder kurz nicht reagiert, blockiert möglicherweise eine längere Schreibtransaktion die Warteschlange.

Das passiert, wenn eine Aktion deutlich länger dauert als üblich und spätere Schreibaktionen warten müssen.

Häufige Ursachen sind:

• Aufrufe externer Dienste, zum Beispiel mit http(...)

• große Datenauswertungen in Kombination mit select

• komplexe Logik in Buttons oder Automatisierungen, die viele Datensätze aktualisiert

Wie du langsame Schreibtransaktionen vermeidest

Halte Schreiblogik fokussiert und kurz.

Diese Gewohnheiten helfen:

• Lies und bereite Daten zuerst vor, wenn möglich.

• Halte API-Aufrufe wenn möglich aus kritischen Schreibabläufen heraus.

• Vermeide wiederholte select-Abfragen innerhalb von Schleifen.

• Teste Buttons und Automatisierungen mit realistischen Datenmengen.

• Teile große Updates wenn möglich in kleinere Schritte auf.

Eine praktische Denkweise dazu

Nutze Lesetransaktionen, um Daten zu prüfen.

Nutze Schreibtransaktionen nur dann, wenn du eine Änderung speichern musst.

Je weniger Arbeit eine Schreibtransaktion erledigen muss, desto flüssiger fühlt sich die App für alle an.