0

Sehr langer Text in Datenfeld - Best Practice

Hallo zusammen, 

ich nutze Rohdaten zur Erzeugung einer Landkarte. Die Rasterdaten werden von Word als 615.000 Wörter auf 789 Seiten dargestellt. Jeder meiner Datensätze (200) enthält einmal diese Daten. 

Nun habe ich gelernt, dass Ninox in manchen Fällen nicht nur die sichtbaren Felder des Datensatzes lädt, sondern auch die unsichtbaren Felder. Das ist bei diesen Datensätzen natürlich enorm aufwendig und geht auf die Performance. 

Was wäre in diesem Falle ein Best-Practice, um unnötiges Laden dieser Daten zu vermeiden?

Rahmeninformation: Monatlich lade ich eine .asc Datei herunter. Kopiere diese Daten in ein Textfeld in einem Datensatz in der Tabelle A. Nun läuft ein "on change-trigger" auf diesem Feld der mir für jeden Datensatz in B aus dem langen Text in dem Feld A.A einen Wert exportiert und in eine Datenbank C (Unterdatenbank von B) schreibt. Wenn ein neuer Datensatz in B dazu kommt, dann werden aus allen Datensätzen in A wiederum ebenso der jeweilige Wert exportiert und in C geschrieben. 

-> Ich brauche also die Informationen in A.A regelmäßig (ca. 10-20 Mal im Monat). Aber: Der Datensatz aus Tabelle A wird ca. 1.000 Mal pro Monat mit weiteren Datensätzen verknüpft. 

Es bleibt also die Frage: Wie kann ich verhindern, dass die Daten aus A.A zu häufig geladen werden, auch wenn man sie eigentlich gerade gar nicht benötigt.

Verständlich?

Danke und beste Grüße

3 Antworten

null
    • Pushing the Boundaries of Ninox
    • Gotje_Ing
    • gestern
    • Gemeldet - anzeigen

    Moin,

    wenn der Gesamt-Textumfang nicht dauerhaft gebraucht wird, sondern nur einmalig um einen kleinen oder gar winzigen Teil in andere Records zu schreiben, dann wäre es sinnvoll das Feld für den Import auf "Speichern im Browser" zu setzen. 

    Ansonsten empfiehlt sich das als Datei abzulegen und nur bei Bedarf mit einem http("GET"...) abzurufen. Statt dem "on Change" Trigger wäre dann ein Button mit dem http() für den Import anzuwenden. 

    Wenn es unausweichlich ist, dass die Daten dauerhaft in einem Textfeld stehen, was höchst unwahrscheinlich ist und den kompletten Datenfluss in Frage stellt, dann wäre eine letzte Option eine Untertabelle zu erstellen, in der ausschließlich die extrem langen Daten liegen. Dort den Änderungslog ausschalten. Verknüpfe diese Tabelle mit A. Dann ist das Handling der Datensätze in A, also select Befehle und sowas, deutlich schneller. 

    Grüße Philipp

      • pma_mgmt
      • vor 6 Stunden
      • Gemeldet - anzeigen

       

      Hallo Philipp, 

      vielleicht gibt es eine bessere Idee: 

      Auf einem Server dessen Angebot ich nicht ändern kann liegt pro Monat eine .zip-Datei mit einem gewissen Namen. In dieser .zip-Datei ist eine .asc-Datei. Ich lade die zip-Datei in ein Bildfeld. Dann muss ich die Datei herunterladen, öffnen, den Text in mein Textfeld kopieren. Dann werden 300 Datensätze mit den Zahlen aus diesen Daten gefüttert und jeweils eine Zahl in Ninox erfasst.

      Allerdings gibt es noch den zweiten Fall: Ich erstelle einen neuen Datensatz. Dann müssen nochmal alle langen Texte durchgegangen werden, um für diesen neuen Datensatz für den jeweiligen Monat ebenfalls die Zahl zu ermitteln. Nur für diesen Fall muss ich die Daten vorhalten. 

      -> Wenn ich aber z.B. die zip-Datei entpacken, und die asc direkt lesen könnte, dann müsste ich die Daten für den zweiten Fall nicht vorhalten.

      Grüße

      Peter

      • pma_mgmt
      • vor 6 Stunden
      • Gemeldet - anzeigen

         - Danke für den Anstoß. Ich habe nun kurzerhand einen PHP-Service aufgebaut, welcher mir die Zip vom Server lädt und als text anbietet. So kann ich jederzeit auf die Ursprungsdaten zugreifen und brauche den Inhalt nicht in Ninox. Danke für deine Unterstützung!

Anmelden, um zu antworten

Content aside

  • vor 6 StundenZuletzt aktiv
  • 3Antworten
  • 24Ansichten
  • 2 Folge bereits