Bei den folgenden Best Practices handelt es sich um zentrale Empfehlungen, die sich im Umgang mit der Plattform als besonders wirkungsvoll erwiesen haben. Sie adressieren typische Schwachstellen wie ineffiziente Datenzugriffe, unerwünschte Trigger-Kaskaden und schleifenintensive Berechnungen. Durch konsequente Anwendung dieser Hinweise lassen sich Ladezeiten reduzieren und Systemressourcen schonen.

1. Ansichten bei großen Tabellen optimieren
   Wenn Sie mit großen Tabellen arbeiten, filtern Sie die erste Ansicht so, dass nur ein relevanter Ausschnitt der Datensätze angezeigt wird – idealerweise nur die wirklich benötigten. Dies reduziert die Ladezeit erheblich und sorgt für eine bessere Benutzererfahrung.
    

2. Konflikte und Zirkelbezüge bei Triggern vermeiden
   Stellen Sie sicher, dass Trigger unabhängig voneinander funktionieren und sich nicht gegenseitig beeinflussen. Vermeiden Sie insbesondere Konfigurationen, die zu Zirkelbezügen oder ungewollten Trigger-Schleifen führen.
    
3. Select-Anweisungen gezielt einsetzen
   Verwenden Sie select-Anweisungen nur dann, wenn es keine effizientere Alternative gibt. Wenn eine Verknüpfung zur Zieltabelle bereits besteht, nutzen Sie diese. Bei Untertabellen (wenn die Untertabelle direkt und ohne ein select aufgerufen wird) muss die Bedingung stets in eckigen Klammern notiert werden, da ein where beim direkten Aufruf der Untertabelle nicht zur Verfügung steht. Zum Beispiel:

   sum((Rechnungspositionen[Artikeltyp = 2].Gesamt)

   
   Vermeiden Sie, das folgenden Skript, da die Zuordnung der Rechnungspositionen zur Rechnung bereits automatisch über die Untertabelle erfolgt, so wie oben:

4. let me:=this;
   sum((select Rechnungspositionen where Rechnung= me and Artikeltyp = 2).Gesamt)

    

5. Select-Anweisungen in Funktionsfeldern vermeiden
   Vermeiden Sie select-Anweisungen in Funktionsfeldern, die in Tabellen- oder Formularansichten angezeigt werden. Falls doch notwendig, verwenden Sie die where-Klausel anstelle von eckigen Klammern ([ ... ]) für Bedingungen – das verbessert Übersichtlichkeit und Performance.
    
6. Select-Ergebnisse wiederverwenden
   Führen Sie eine select-Anweisung innerhalb eines Skripts nur einmal aus und speichern Sie das Ergebnis in einer Variablen. Greifen Sie anschließend über diese Variable auf die benötigten Felder zu – so vermeiden Sie Mehrfachzugriffe auf die Datenbank.
    
7. Select-Anweisungen in verschachtelten Schleifen vermeiden
   Vermeiden Sie select-Anweisungen innerhalb verschachtelter Schleifen. Wiederholte Datenbankzugriffe in Schleifen führen zu schlechter Performance.
    
8. Statische Werte statt dynamischer Berechnung verwenden
   Formeln sollten nicht bei jeder Anzeige neu berechnet werden, wenn der Wert sich selten ändert. In solchen Fällen ist es besser, den Wert per Trigger einmalig in ein Datenfeld zu schreiben – das spart Rechenleistung und beschleunigt das System.
    
9. Effiziente Suchen aus Dashboard-Formularansichten
   Wenn eine Formularansicht als Dashboard genutzt wird, definieren Sie alle Suchparameter zuerst mit let und führen Sie anschließend eine gezielte select-Abfrage aus. Begrenzen Sie das Ergebnis z. B. auf 100 Datensätze, um unnötige Datenmengen zu vermeiden. Leere Suchfelder sollten Sie mit dem not-Befehl korrekt behandeln. Beispiel:

   let mySearch := 'Projekt suchen';
   select Projekte where (not mySearch or Projektname + concat ('Projekt Mitarbeiter'. 'Person auswählen'

    

10. Große Texte nicht in Textfeldern speichern
    Vermeiden Sie die Speicherung großer Inhalte – wie CSV-Dateien für Importe oder JSON-Payloads für API-Aufrufe – direkt in Textfeldern. Da Ninox jede Änderung protokolliert, kann dies die Änderungshistorie unnötig aufblähen.
    Besser ist es, solche Inhalte mit createTextFile() als Anhang zu erzeugen und bei Bedarf über die API darauf zuzugreifen.
     

11. Indizierung gezielt nutzen
    Verwenden Sie Indizes nur für Felder, die sehr viele unterschiedliche Werte aufweisen und die tatsächlich häufig durchsucht oder gefiltert werden. Bei Felder mit wenigen möglichen Werten (z. B. Ja/Nein) ist das Setzen eines Index' nicht sinnvoll, weil unwirksam und kann sogar zur Verlangsamung der Suche führen. Auch das Setzen des Index and sehr vielen oder sogar alle Feldern einer Tabelle kann diesen gegenteiligen Effekt verursachen, weshalb nur ausgewählte Felder indiziert werden sollten (siehe oben im Absatz). 
    In Tabellen, in denen regelmäßig Datensätze gelöscht werden, empfiehlt es sich, die Indizes gelegentlich über die Datenbankoptionen zurückzusetzen.