Berechnungsfelder verlangsamen

Warum sollte man statt ein Berechnungsfeld normale Text- oder Nummernfelder verwenden? Ein wichtiger Grund kann in der Indexierung liegen.

Berechnungsfelder werden stets aktualisiert und können deshalb nicht indexiert werden. Felder, die stets aktualisiert werden, verlangsamen jede FileMaker Lösung. Das macht sich insbesondere bei grossen Datenmengen in Listenansichten bemerkbar, sowie bei Scripts, die auf Layouts zugreifen müssen, worin Berechnungsfeldern liegen.

Normale Text- und Nummernfeldern dagegen werden meist automatisch indexiert und können deshalb schnell Resultate liefern – es muss nichts mehr berechnet werden. Es ist sinnvoll, Berechnungen in normalen Text- und Nummernfeldern auszulösen, aber nur im Bedarfsfall. Grösstenteils müssen Angaben nur einmal berechnet werden und vielleicht später noch einmal in einer Korrektur. Mehrheitlich ist eine ständige Neuberechnung nicht erforderlich und belastet das System nur unnötig.

Will man performante Lösungen erstellen, sind Berechnungsfelder häufig ein Flaschenhals. Deswegen kann es sich lohnen nach Alternativen Ausschau zu halten.

Berechne den Text

Texte können zusammengebaut werden. Ein typisches Anwendungsgebiet sind Adressblöcke. Man kann etwa eine Adresstabelle mit folgenden Feldern haben:

<Firma>
<Strasse>
<Postleitzahl> <Ort>.

Dies ist nur ein vereinfachtes Beispiel. Die meisten Adressen sind deutlich komplexer. Damit man diese Angaben nicht ständig neu zusammensetzen muss, kann es sinnvoll sein, ein separates Feld für eine <Komplettanschrift> zu erstellen. Darin kann man die gesamte Adresse abbilden. Bei Briefen, Rechnungen und dergleichen muss man nur auf das vorberechnete Feld der <Komplettanschrift> verweisen. Weil das berechnete Feld ein normales Textfeld ist, kann dieses Feld indexiert werden. Es geht in diesem Beispiel um das Prinzip, nicht um diese spezielle Lösung, welche als Beispiel herbeigezogen wird.

Das Resultat soll in das neutrale Textfeld <Komplettanschrift> geschrieben werden. Es gibt mehrere Optionen, dies zu lösen:

1. Per Script (Feldwert setzen + Berechnung im Script)
2. Per Felddefinition (Definition im Feld selbst)
3. Per Felddefinition (Definition in einem externen Referenzfeld)

Die Berechnung findet also nur 1x statt. Sie sollte aber bei Bedarf wiederholt werden können.

Hier liegen nun die Unterschiede zu einem Berechnungsfeld: Bei einem regulären Text- oder Nummernfeld muss man die Berechnung speziell auslösen, während bei einem Berechnungsfeld ständig aktualisiert wird. Daraus folgt selbstverständlich, dass die Entwicklung mit regulären Feldern etwas aufwändiger ist. Die Belohnung liegt jedoch in einer performanteren Lösung und steuerbaren Resultaten.

Mehrere Trigger für die Berechne-Funktion

Die Berechne-Funktion unterstützt nur 1 Trigger. Das ist eine Begrenzung. Es funktioniert recht einfach: Ändert sich der Inhalt des Trigger-Feldes, dann wird die Berechnung ausgeführt. Bei komplexen, verschachtelten Berechnungen und bei externen Feldern kann die Berechnung stocken. Ein Trigger kann sie aber gezielt wieder zum Laufen bringen. Das ist die Aufgabe des Triggers.

Nur 1 Trigger steht zur Verfügung. Manchmal stehen aber mehrere Felder in einer Berechnung, worauf die Berechne-Funktion nicht wirkt. Diese Felder kann man in ein neues Feld zusammenrechnen (addieren!), damit daraus ein Wert entsteht. Ändert sich nun in einem der addierten Felder etwas, dann ändert sich auch die Summe im separaten Trigger. Das separate Feld wird also nur angelegt, damit eine sonst nicht entdeckte Änderung trotzdem zu einer Neuberechnung führt. Es ist ein Hilfsfeld.

Als Triggerfeld habe ich ein Nummernfeld angelegt, worin ich die relevanten Schalter für diese Berechnung «zusammengezählt» habe. Das Ergebnis ist nicht wichtig. Es wird jedoch zuverlässig jede Änderung in den Schalter-Feldern berücksichtigen. Die Änderung triggert nun die Berechnung der <Komplettanschrift>.

Einsatzgebiete

Lösungen wie diese helfen dabei, eine Anwendung zu optimieren. Das einzige Ziel dabei ist es, Berechnungsfelder zu vermeiden, weil die ständig Ressourcen benötigen. Reguläre Textfelder dagegen können indexiert werden. Die Techniken in diesem Beitrag zeigen, wie man eine Berechnung bei Bedarf in einem regulären Textfeld triggert.

Beispiel

Im folgenden kurzen Video wird das Ergebnis des letzten Beispiels gezeigt. Die Adresse rechts im Bild wird mit verschiedenen Schaltern formatiert. Das Ergebnis wird in ein reguläres Textfeld gespeichert. Das Beispiel zeigt, wie man mit regulären Feldern Berechnungen ganz ohne Berechnungsfelder bei Bedarf ausführen kann.

Das KISS-Prinzip

Anfangs der 1960er-Jahren wurde von der amerikanischen Navy ein Grundsatz für gutes Design geprägt. Unter dem Akronym «KISS» verbirgt sich die Idee, alles möglichst einfach zu halten. KISS steht für

• Keep it simple, stupid
• Keep it simple & smart
• Keep it simple & sweet
• und so weiter.

Der Grundsatz besagt, dass man das Design so einfach wie möglich halten soll. Die Vereinfachung des Designs soll verschiedene Vorteile bieten. Das Prinzip lässt sich auf unterschiedlichste Bereiche anwenden. In einer Softwareentwicklung könnte man mögliche Vorteile wie folgt auflisten:

• bessere Übersichtlichkeit
• einfacher zu bedienen
• einfacher zu warten
• verwendet weniger Ressourcen.

Einfacher ist aus diesen Gründen besser. Das KISS-Prinzip hat sich in vielen Situationen als nützliche Idee erwiesen. Die Herausforderung liegt jedoch in der Vereinfachung.

Einfacher oder vollständiger?

Wie lässt sich das KISS-Prinzip anwenden? Gibt es für die Vereinfachung auch Grenzen?

Oft kann man eine Funktion auf einen einzigen Script-Schritt reduzieren. Wer etwas erreichen will und das durch einen einzigen Script-Schritt erreichen kann – anstelle durch viele komplexe Zwischenschritte – hat etwas gut verstanden. Das wäre analog dem KISS-Prinzip. Einfacher ist besser.

FileMaker ist stark in diesen Dingen, weil es komplexe Sachverhalte oft auf einen konfigurierbaren Script-Schritt reduziert. Allerdings ist diese Vereinfachung zwar zielführend, aber nicht immer maximal deutlich. Das möchte ich anhand eines Beispiels aufzeigen.

Stufe 1: Der Minimalist

Wer etwas mit nur einem Script-Schritt lösen kann, zeigt sich als Meister. Simple is beautiful. Das hat jedoch Grenzen. Bei vielen Script-Schritten lassen sich Berechnungen einfügen. In der Script-Übersicht sind diese Berechnungen meist nicht oder nur teilweise sichtbar.

Erst ein weiterer Klick und ein weiteres Fenster zeigen, welche Berechnung im Hintergrund liegt. So funktioniert das in FileMaker. Eventuell sieht man gar nicht, dass eine Berechnung hinterlegt ist. Dann ist zwar die Funktion sehr einfach, aber die Darstellung in FileMaker verhüllt auch bestimmte Abläufe. Das hat Vor- und Nachteile, ist jedoch für die Übersichtlichkeit nicht optimal.

Stufe 2: Der Erfahrene

Eine mögliche Lösung wäre es, die Berechnung durch einen Variablen zu ersetzen und die Variable selbst der Funktion vorauszusetzen. Man kann so vorgehen, dass Berechnungen immer in Variablen stattfinden. Der Name einer Variablen kann einen Hinweis auf die Berechnung liefern. Es wird übersichtlicher. Damit gäbe es zwei Scriptschritte:

• Setze Variable (mit Berechnung)
• Benutze Variable (in der eigentlichen Funktion).

Dieses Vorgehen teilt in zwei Schritte auf, was auch in einem Schritt ginge. Der Vorteil liegt hier nicht in der «möglichst kürzesten Umsetzung», sondern eher in der Übersichtlichkeit. Wer das Script aufschlägt, sieht in der Übersicht Variable und Anwendung in zwei Schritten nacheinander. Ein Schritt mehr kann verdeutlichen, dass hier etwas berechnet wird und damit kann die Übersichtlichkeit gedient sein.

Stufe 3: Der Weise

Die Überlegungen können noch weitergehen. Es kann hilfreich sein, zusätzlich ein kurzer Kommentar zu erfassen. Viele Entwickler haben festgestellt, dass eine gut-kommentierte Softwarelösung später einfacher zu warten ist. Ein Kommentar wird demnach im Hinblick auf die spätere, einfachere Wartung angelegt. Wir haben nun drei Zeilen:

• Kommentar
• Setze Variable
• Benutze Variable (in Funktion)

Evaluation der Entwicklung

Was ist jetzt besser, die kürzere direkte Umsetzung oder die besser lesbare Variante mit einer Erklärung für später? Mit diesem Beispiel möchte ich aufzeigen, dass das KISS-Prinzip gut ist, jedoch können Gründe dafür sprechen, eine Aufgabe etwas ausführlicher umzusetzen.

Wo liegt hier der Unterschied? Der Unterschied liegt in der Bewältigung der Komplexität, aber auf zwei verschiedene Ebenen.

1. Die Funktionalität
   Wer ein komplexer Vorgang auf einen einzigen korrekten Script-Schritt reduzieren kann, hat die Möglichkeiten von FileMaker (oder einer anderen Entwicklungsplattform) gut erfasst. Das ist der Kern, um den es geht. Die Bewältigung der Komplexität konnte durch eine starke Vereinfachung erreicht werden.
2. Die Darstellung
   Die beiden weiteren Zeilen, die nun hinzugefügt werden (Kommentar und Variable) befassen sich nicht mehr mit der Funktionalität, sondern verbessern lediglich die Darstellung. In der Übersicht ist dadurch auf Anhieb klar, was gemeint wird (Kommentar) und wo man eine Berechnung prüfen sollte (Variable).

Es gibt so viele Meinungen zum Thema, wie es FileMaker-Entwickler gibt. Mir geht es hier nicht darum, zu entscheiden, was wichtig ist, oder wie man etwas machen «sollte». Dieser Beitrag ist bloss eine Reflexion. Heute sehe ich deshalb die drei genannte Schritten als Entwicklungsansätze:

1. Funktion (Minimalismus)
2. Variable (Erfahrung)
3. Kommentar (Weisheit)

Besonders wichtig: Der Minimalist hat gute Gründe, genau so vorzugehen, und keine Zeile zu viel zu schreiben. Wer Berechnungen sichtbar macht, hat aus seiner Erfahrung gelernt, dass dadurch die Scripts besser lesbar sind. Wer ausserdem noch Kommentare hinzufügt, hat verstanden, dass er selbst nach einem Jahr vermutlich nicht mehr weiss, warum das Script so und nicht anders geschrieben wurde. Von jedem Ansatz lässt sich etwas lernen.

Vereinfachung der FileMaker Entwicklung

Das KISS-Prinzip ist nur eines von vielen Möglichkeiten, eine Vereinfachung anzustreben. Selbstredend gibt es weitere Möglichkeiten, die FileMaker Entwicklung zu vereinfachen. Dabei stelle ich fest, dass es verschiedene Ansätze gibt. Welche Variante man bevorzugt, hängt möglicherweise vom eigenen Temperament ab oder von besonderen Anforderungen des gerade aktuellen Projektes. Welche sind die Varianten?

1. Mehr Regeln
   Einige streben Systeme an, worin alle Details der Entwicklung definiert sind. Es gibt nicht bloss «best practices», sondern man stellt ein Regelwerk auf, wonach sich der Entwickler zu richten hat. Für alles gibt es eine Definition: Wie man Dinge benennt (etwa Feldnamen, Tabellen, Layouts), wie man sie referenziert und welche Konzepte für die gesamte Applikation gelten.
   Nachteil eines Regelwerkes: Es kann ein Eigenleben anfangen und viele Ressourcen und Zeit binden.
   Bedenkenswert: Ein Regelwerk soll dem Entwickler helfen und der Entwickler soll nicht dem Regelwerk dienen.
2. Weniger Regeln
   Andere, vermutlich die meisten Entwickler, richten sich nach «best practices» und einem reduzierten Regelwerk. Ganz ohne eigene Vorgaben wird man nicht auskommen, aber der Fokus liegt nicht auf dem Regelwerk, sondern auf einer Struktur. Die Struktur soll dem Entwickler helfen, sich jetzt und auch in Zukunft zurechtzufinden. Nicht «wie» man etwas macht, sondern «wo» man etwas findet, steht zentral.
   Nachteil eines Struktur-Prinzips ist gerade die Freiheit des Entwicklers.
   Bedenkenswert: Entwickler tun gut daran, sich bewusst eine Struktur zurechtzulegen und diese konsequent zu nutzen.

Die Vereinfachung der Entwicklung hat immer etwas von einem Abenteuer. Welche Dinge sich bewähren, wird man erst im Nachhinein feststellen. Man braucht den Mut, nicht nur aus der eigenen Erfahrung, sondern auch von anderen Kollegen dazuzulernen, Fehler zu machen, und bewährte Ansätze sukzessive in die eigene Arbeit einfliessen zu lassen.

Wer lernend unterwegs ist, wird feststellen, dass man sich ändert, mit der Zeit bessere Entscheidungen trifft und rückblickend vieles etwas chaotisch gemacht hat. Es braucht Mut zur Lücke, wenn man das feststellt. Selten nämlich lassen sich die alten Fehler neu programmieren. Manchmal jedoch ist es unerlässlich. Dieser Prozess ist spannend und es gibt Methoden, den Schmerz in Grenzen zu halten. Vereinfachung ist eines dieser Methoden.

KISS: Keep it simple & smart.