Ninox Performance Regeln
Hallo zusammen,
Ich habe ein Schema in Ninox umgesetzt, mit kleinen Datenmengen getestet und nun von außen mit größeren Datenmengen über die API gefüttert. Nun merke ich, dass das öffnen von Tabellen sehr lange dauert. Eine Tabelle, auf der ich ein serverseitiges Skript gestartet habe, antwortet gar nicht mehr. Gibt es Ninox-Faustregeln für Performance? Ich meine so etwas wie:
- Möglichst keine Volltextsuche
- Tabellen-Verknüpfungen über Ids und nicht über Zeichenketten?
Einiges kann ich mir zwar schon denken, aber vielleicht gibt es Do’s and Dont’s? Manche der Berechnungen, die ich anstelle, hätte ich z.B. lieber zeitgesteuert und im Hintergrund gestartet, als über Trigger gelöst - weiß nur nicht wie.
Gruß
Sergej
14 Antworten
-
Hallo Sergej, um welche ungefähren Größenordnungen der Datenmengen geht es? Ich habe bisher nur mit Tabellen im maximal niedrigen vierstelligen Bereich gearbeitet und hatte dabei nie Performance-Probleme. Gehört habe ich aber auch schon von sechsstelligen Datensatzzahlen. Deshalb wäre es zur Einordnung interessant, bei Berichten über Performance-Probleme auch quantitative Angaben zu haben. Danke sehr.
-
Hi Copytexter. Aktuell sind es ca. 50.000 Datensätze / Tabelle und sollen ca. 300.000 werden. Gruß Sergej
-
Danke für die Info. Okay, bei solchen Zahlen können Code-Optimierungen wahrscheinlich bei jeder Datenbank einiges bewirken, insbesondere bei webbasierten. Hoffe, du bekommst da noch ein paar Tipps.
-
Meiner Erfahrung nach, sind es die Berechnungsfelder, die bei großen Mengen für den Ärger sorgen. Also Keine Berechnungsfelder als Spalten.
Leo
-
"Keine Berechnungsfelder als Spalten." kannst Du das ein wenig erläutern... die ganze Ninox Datenbank arbeitet doch Spalten- und Datensatzbasierend..
-
Ich denke, Leo meint, dass man in den Tabellenansichten nur keine Funktions(!)felder anzeigen lassen sollte, mit denen ein Ergebnis berechnet wird. Erscheint mir durchaus plausibel, denn wenn man 50.000 Datensätze hat, muss die Berechnung ja auch 50.000 mal durchgeführt werden. Im Gegensatz zur Formularansicht, wo sie jeweils nur einmal durchgeführt wird. Normale Datenfelder wären davon nicht betroffen.
-
das kann ich mir irgendwie nicht vorstellen.. Teile meiner FX brauchen Ergebnisse aus der Gesamten Datenbank und mancher Trigger korrigiert Ergebnisse über alle Datensätze..
ich schaufle mich hier gerade in meiner Sparte durch 15 Personen aus 385 *(365/2) Datensätze =2738 + ~236 für Ersatzkräfte..
Das Vorgeschrieben für zwei Monate und immer von Anfang an neu durchgerechnet.
Das Rechnen macht keine Probleme nur das Erstellen und das ließ sich mit "do as server" über Leos Tipp beseitigen..
aber ich will dem Fred nicht Kapern... interessant wäre es trotzdem wenn er es erklären könnte
-
Hallo Martin,
die Erklärung liegt, wie der Copytexter schon sagte, an der Natur der Sache. Die Berechnungen an sich verlaufen sehr schnell, sagen wir 0,0001s. bei 3000 Datensätze sind das 0,3 s.-Blitzschnell. Bei 300.000 Datensätze ist es aber schon 30s. usw. Deswegen nach Möglichkeit die Werte nach Eingeben berechnen und die Werte in die Felder schreiben.
Was die Datenbank noch enorm verlangsamt, sind die Schleifen und select Anweisungen.
Leo
-
"Was die Datenbank noch enorm verlangsamt, sind die Schleifen und select Anweisungen"
oh ja das habe ich bemerkt und zwar leidvoll
-
Danke Leo, ich habe nun die ganzen FX Tabellen ausgeblendet... absolut der Wahnsin.. ich bin von 10 Sek Aktualisierung pro Datensatz auf nicht messbar quasi per klick gekommen.. das ist krass vielen Dank nochmals..
-
Das mach Sinn. In einer Ansicht kann ich sortieren, Aggregatfunktionen anwenden und filtern. Daher ist es egal, ob ich nur die ersten 100 Zeilen zu sehen bekomme - berechnet werden müssen sie alle.
Um Funktionsspalten zu vermeiden, sollten die Werte also nach dem Ändern des Datensatzes berechnet werden. Bedeutet aber auch, dass manch berechneter Wert von außen kommen müsste.
Will ich z.B. wissen wieviele
Produkte2018 verkauft wurden, müsste ich einen Trigger in der Tabelle derBestellungenbauen, der nach der Änderung einer Bestellung die verkaufte Stückzahl des referenzierten Produkts neu berechnet und in das passende Feld im jeweiligen Produkt schreibt. Das funktioniert aber nur für absolute Zeiträume. Will ich dagegen wissen, wieviele Produkte ich die letzten 30 Tage verkauft habe, komme ich um eine Funktion in der Ansicht nicht herum.Vom Support habe ich noch den Tipp bekommen die Spalten aus meinen Select-Anweisungen zu indexieren. Das hat bereits einiges gebracht.
-
Ich nehme meinen Hinweis mit dem "Index" erstmal zurück. Es scheint mir, dass indexierte Spalten nicht gefiltert werden können. Bin mit dem Ninox Support in Kontakt.
In der Tabelle
Produkthabe ich ein FeldSKUund einen Datensatz mit dem Wert "MYSKU". Die Anfragecount(select Produkt where SKU = "MYSKU")liefert mit eingeschaltetem Index überSKUeine0und ohne Index eine1. -
Hallo Sergej, versuch mal mit Eckklammern statt where:
cnt(select Produkt[SKU = "MYSKU"])Ich habe in der letzen Zeit mehrmals bei where ein Fehlverhalten festgestellt
Leo
-
Tatsache Leo!
count(select Produkt[SKU = "MYSKU"]) = count(select Produkt where SKU = "MYSKU") => FALSE.Gruß Sergej
P.S. Guten Rutsch an alle.
Content aside
- vor 5 JahrenZuletzt aktiv
- 14Antworten
- 4238Ansichten