4

Was machen mit den gespeicherten Files in der Ninox_DB?

Das Gute an Ninox ist auch, dass man die Apps nutzen kann um direkt Fotos für den Record zu erstellen. Solange man die reine App nutzt und auch die Datenbank auf dem eigenen Rechner oder in der iCloud speichert, muss man sich eigentlich keine Gedanken um die Datenbankgröße machen. Wie man weiss, blähen Bilder/Videos und dazu gehören auch die in Ninox erstellten und abgespeicherten Druck-PDF's, die Datenbankgröße auf.
Wenn man nun die Public-Cloud von Ninox nutzt, kann man durch die neue Verbrauchsübersicht (Zahnrad im Teammenü) nachsehen, was sich da so im Laufe der Zeit an Volumen angesammelt hat. (Hätte ich nicht machen sollen)
Wie kann man dem entgegenwirken.
Eine Möglichkeit besteht wohl darin, seinen Ninox Kapazität monetär aufzustocken.
Mein Lösungsansatz besteht darin, die Datenbank zu verschlanken, indem ich die Dateien auslagere. Es gibt einige Lösungen auf dem Markt: NextCloud, Seafile, Baserow etc., welche man auch selbst hosten kann. Ich habe mich für Baserow entschieden und nutze n8n (wobei es sicherlich auch mit Make funktionieren würde) um die Files auszulagern und nur noch einen Sharelink auf das File in Ninox zu behalten. Einen Drittanbieter wie n8n deshalb, weil man bei Baserow vor dem Upload einen Zertifizierungsschlüssel benötigt und aus Ninox keine Bilder direkt irgendwohin laden kann. Bei Bildern hat man noch den Vorteil, über Thumbnails eine kleine Vorschau zu erhalten. In meinem Fall, werden die Ninox-DB'en, bei denen ich es schon anwende erheblich verkleinert und der Arbeitsfluss innerhalb Ninox läuft auch smooth. Das System funktioniert auch mit den Apps (Ich nutze das iPhone um Kassenbons zu fotografieren und über ein OCR automatisch den gezahlten Betrag/Datum in Ninox einzutragen) Nach dem OCR lagere ich das Foto direkt aus und halte die DB damit klein.
Ein Beispiel der Funktionsweise für das Auslagern und wieder importieren von Files findet ihr im NX-API Team in der Carbone Bsp. DB in der Tabelle Bilder. Man kann es direkt im Team testen, da kein Ninox API-Key benötigt wird. Voraussetzung ist jedoch ein Ninox ABO, da Sharlinks zur Übertragung erzeugt werden und das nur mit den Ninox Cloudversionen funktioniert.

Ich kann auch mal eine reine NinoxDB zum ausprobieren in das Team laden, welche nur den Upload /Import  ohne SchnickSchnack zeigt und den n8n Flow beinhaltet.

So sieht mein n8n Flow zum Übertragen per Webhook aus:
 

So sieht die Baserow Tabelle aus:
 

Wie bereits angesprochen, ist dies meine persönliche Lösung und dient nur zur Anregung. 

41 Antworten

null
    • Dr_Stefan_Philipp
    • vor 11 Monaten
    • Gemeldet - anzeigen

    Lieber UweG,

    da ich mich mit dem gleichen Problem einer stetig zunehmenden Datenbankgröße herumplage und im Forum auf diesen Thread gestoßen bin, möchte ich kurz meine Situation skizzieren und danach eine Frage stellen:

    a) In konkreten Fall handelt sich um eine ziemlich komplexe medizinische Datenbank (50 Tabellen) in der Public Cloud zur Befunderstellung und Arztbriefschreibung. Zur Befunderstellung existiert eine einzige Tabelle, an die während einer Untersuchung oder Operation erstellte Bilder als Dateianhang angehängt werden können.

    b) Nach Import der Dateien als Dateianhang wird ein Button gedrückt, der die Bilder in eine Tabelle namens "Bilder" kopiert und dann alle Dateianhänge löscht.

    c) Für jedes neue Bild wird ein neuer Record in der Tabelle Bilder erstellt. Dies löst bei Zapier ein Zap aus, dass die Bilddatei in die Dropbox verschiebt, anschließend das Original löscht und durch einen Download-Link ersetzt.

    d) Ein ähnlicher Zap existiert auch für jede neue PDF-Datei.

    e) Somit enthält die Datenbank weder Dateianhänge noch gespeicherte Bilder oder PDF-Dateien; alles ist in die Dropbox verlinkt.

    f) Bei der Erstellung eines Arztbriefes werden diese Bilder temporär heruntergeladen, in das Dokument eingepflegt und nach Fertigstellung des PDF-Dokuments wieder gelöscht.

    Dennoch wächst die Datenbank ständig an und hat seit ihrem Start in den Produktivbetrieb Ende August 2023 bereits eine beachtliche Größe: Erstelle ich ein Backup mit Files, dann beträgt die Größe der heruntergeladenen Datei 688 MB. Das Backup ohne Files ist gerade mal 2,3 MB groß.

    Somit ergibt sich meine Frage:

    Kann es sein, dass Ninox die importierten Bilddateien irgendwo auf dem Server speichert, obwohl sie clientseitig gelöscht werden?

    Für diesen Umstand spricht die Auskunft des Supports, dass man bei Überschreiten der max. Speicherkapazität ein Backup erstellen und herunterladen solle. Dieses wäre nach dem Zurück-Importieren unter Umständen kleiner als die Original-Datenbank.

    Falls die Dateien auf dem Server gespeichert werden:

    Unter welchen Umständen tritt dieses Phänomen auf und wie kann es vermieden werden?

    Herzliche Grüße

    Stefan

      • Dr_Stefan_Philipp
      • vor 11 Monaten
      • Gemeldet - anzeigen

      Icarus - Ralf Becker UweG

      Lieber UweG,

      zu deiner Verständnisfrage: Beim Erstellen eines Backups wird gefragt, ob dieses mit oder ohne Files erstellt werden soll.

      Ich habe jetzt probeweise ein Backup meiner Datenbank ohne die Option 'Include Files' erstellt und reimportiert. Das Backup ohne Files ist 2,3 MB groß. Nach dem Reimport dieses Archivs in die Ninox-Cloud habe ich probeweise einige Bilder in die Tabelle 'Bilder' importiert, anschließend einen Freigabelink in der Dropbox erstellt und diesen in der Datenbank gespeichert. Dabei löscht eine einfache und durch einen Änderungstrigger gesteuerte Funktion die Bilddatei durch den Befehl 'Bild := null', sobald Dropbox diesen Freigabelink erstellt und via Zapier im betreffenden Datensatz gespeichert hat.

      Dabei könnte man annehmen, dass die Bilddatei gelöscht wird.

      Erstellt man nun aber erneut ein Backup mit der Option 'Include Files', dann ist dieses Backup etwas mehr als 20 MB groß. Lokal kann man das Backup mit z. B. Keka entpacken, danach sieht man die einzelnen Dateien der Tabelle 'Bilder' ('CC') unter den einzelnen recordIDs (3738-3741).

      Es ist also so, wie Icarus - Ralf Becker geschrieben hat: Das Auslagern von Dateien führt nicht zum Einsparen von Speicherplatz. Somit muss ich bei Erreichen der Speichergrenze ein Backup ohne die Option 'Include Files' erstellen, dieses reimportieren und anstelle der alten Datenbank verwenden, die dann gelöscht werden muss (einschließlich sämtlicher Backups).

      Damit kann ich zwar leben, allerdings erhält die neue Datenbank eine neue ID und ich muss sämtliche Zaps, die darauf zugreifen, manuell aktualisieren.

      Was wär eurer Meinung nach ein geeignetes Feature Request? Sollte Ninox die Option anbieten, nach dem Erstellen und Herunterladen eines manuellen Backups alle Dateien einer Datenbank zu löschen, d. h. alle Dateianhänge als auch alle Dateifelder (was eine Harakiri-Funktion wäre)?

      Liebe Grüße

      Stefan

      • Michi.1
      • vor 11 Monaten
      • Gemeldet - anzeigen

       bitte beachten das Bild:=null nicht die Datei löscht, sondern nur in den Anhang verschiebt 

    • UweG
    • vor 11 Monaten
    • Gemeldet - anzeigen

    Über die Ninox API kann man auch das Bild endgültig in Ninox löschen.

      • Matthias_B
      • vor 8 Monaten
      • Gemeldet - anzeigen

       Das interessiert mich. Wie geht das? Kannst Du den prinzipiellen Weg erklären?

      • UweG
      • vor 8 Monaten
      • Gemeldet - anzeigen

      Das oben angeführte Beispiel habe ich für das Programm Baserow gebaut.
      Da Baserow für die Authentifizierung OAuth2 benötigt und Ninox dies momentan nicht darstellen kann, habe ich mir über das drittprogramm n8n eine Art Vermittttler zwischen Baseroe - Ninox gebaut.
      Man benötigt für dieses Vorgehen etwas Java-Script Kenntnisse und muss sich die Beschreibung der API von Baserow durchlesen.
      Alle wir von Ninox aus über einen http-Request an einen n8n-Webhook gestartet, dem einige Daten aus Ninox mit übergeben werden.
      In n8n werden ,je nach dem welche Aktion durchgeführt werden soll, die einzelnen Nodes abgearbeitet. (siehe Screenshot n8n)

    • T_Bartzsch
    • vor 11 Monaten
    • Gemeldet - anzeigen

    Hallo Stefan,

    das Dateihandling ist in Ninox leider wirklich noch etwas holprig. Wie Michi schon schrieb, Bild := null setzt nur das Bildfeld zurück (leert es) - das hochgeladene Bild ist dann aber trotzdem im Datensatz als Dateianhang abgelegt und nach Bild := null auch dort zu finden (Büroklammer-Icon). Evtl. liegen bei Dir dort auch noch andere "Bildleichen". Ich würde mir in deiner Ansicht mal eine Formel-Spalte mit "files(this)" anlegen, um einen Überblick zuhaben, wo evtl. noch zu löschende Bilder im Datensatz liegen... diese dann entweder manuell, oder über einen "Löschen"-Button über ein Ninox-API-Script löschen.

    Wie ich weiter oben schonmal erwähnt hatte, kann man mit der Dropbox-API direkt OHNE Umwege über Make/ZAP/Node Dateien auslagern, Cloudinary funktioniert auch recht gut und sicher auch noch ein paar andere Cloudspeicher-Dienste. Wichtig bei diesem Workflow ist:

    1. der Dienst muss Rest-API-fähig sein (sind Clouddienste eh...),

    2. der Fileupload muss über URL möglich sein (wegen des Ninox-Sharelinks, evtl geht mittlerweile auch base64 seitens Ninox)  

    3. das hochgeladene File sollte über einen zurückgegebenen "Public-link" aus dem Clouddienst abrufbar sein (OneDrive bzw. SharePoint ist dabei zB. leider sehr bockig...)

    Wenn das gegeben ist, kann man zB ein in ein Bildfeld abgelegtes Bild mit einem Rutsch zu einer OCR-Texterkennung schicken, den Text in einem Textfeld ablegen, das Bild in den Clouddienst auslagern, via Ninox API aus der Datenbank löschen und das ausgelagerte Bild entweder in einem iFrame in Ninox anzeigen, oder ein 200px low-Resolution Thumbnail zurück in das Bildfeld laden... das geht sogar mit Trigger "Nach Änderung..." im Bildfeld.

      • Icarus_Ralf_Becker
      • vor 11 Monaten
      • Gemeldet - anzeigen

      T. Bartzsch ich werde nicht müde darauf hinzuweisen, dass bei deinem Punkt 3. jeder Datenschutzbeauftragte die Hände über dem Kopf zusammenschlägt und diese ganzen Auslagerungs-Workarounds nur deswegen Anklang finden, weil es bisher noch nirgends geknallt hat o. das Thema "Datenschutz" nicht entsprechend wahrgenommen wurde. Dass es nur eine Frage der Zeit ist bis das schief geht, ist selbstredend. Ich kann daher bei Business-Lösungen hiervon nur dringend abraten. Die Abmahnung will keiner zahlen.

      • T_Bartzsch
      • vor 11 Monaten
      • Gemeldet - anzeigen

      ja, da hast Du natürlich vollkommen Recht. Man darf nur nicht vergessen, dass diese ganzen Auslagerungs-Workarounds ursächlich darauf zurückzuführen sind, dass einen Ninox mit 2 GB Speicherplatz dazu "zwingt" nach workarounds zu suchen. Da kann ja seitens Ninox noch alles schön DSGVO-Konform und DE gehostet sein ... wenn ich aber nicht mehr an meine Daten komme, und nichtmal mehr ein Backup möglich ist, weil mir der Speicherplatz voll läuft, muss man eben Lösungen suchen. Mir gefällt das auch nicht, wenn man einem Kunden versucht Ninox zu empfehlen, aber man dann evtl. noch ein Make/Zapier Abo und irgendeine Bastellösung für die PDF mit verkaufen muss. Dann soll Ninox doch bitte reine Speicherplatz Abos anbieten... Ich kann doch nicht einem Kunden 5 Accounts andrehen, damit er auf 10GB Speicherplatz kommt. Sync.com bietet 1TB für 6$, Unlimited(!) für 15$, Cloudinary bietet 25 GB für Free...

      Wie sieht Deine Lösung für deine Kunden denn aus? 

      LG, Tobias

      • Icarus_Ralf_Becker
      • vor 11 Monaten
      • Gemeldet - anzeigen

      T. Bartzsch meine Lösung sieht so aus, sämtlich Anhänge (das sind in der Masse Rechnungen/Aufträge/Angebote etc.) dass in einem frei wählbaren Intervall lokal und gesammelt heruntergeladen werden können. Anschl. werden diese Anlagen aus Ninox gelöscht. Beim Öffnen des Datensatzes werden bei Bedarf die gelöschten Anlagen wiederhergestellt und bei der nächsten Löschroutine wieder gelöscht. So halte ich die Datenbank schlank. Aber das ist natürlich auch nur eine Notlösung.

      Ich habe für das Speicherthema kein Verständnis (mehr), zumal in den letzten Jahren da keinerlei Bewegung zu erkennen ist. Jeder BWLer greift sich auch an den Kopf, wenn man so Kunden zum Lizenzkauf zwingen will, weil jeder weiß, dass die Zahl wo das klappt nur ein Bruchteil derer ist, die man dadurch als Kunde gar nicht erst gewinnt. Ein Unternehmer würde Werbung machen und schreiben "Ninox bietet ab sofort den 5-fachen Speicherplatz pro Lizenz. Und das ist gleichen Preis. Dauerhaft. Und für Neukunden bieten wir 15% Rabatt im ersten Jahr, wenn innerhalb eines Monats eine Lizenz gebucht wird. Und 30% für jede weitere." So oder so ähnlich gewinnt man neue Kunden und Bestandskunden als Multiplikator.

      • T_Bartzsch
      • vor 11 Monaten
      • Gemeldet - anzeigen

       genau... das MEHR bei Verständnis würde ich auch so setzen. Alles in Allem ist Ninox eine tolle Lösung und 2 GB reicht für reine Datensätze ja allemal. Ich würde mir da mehr Flexibilität bei den Paketen wünschen. Medienintensive Datenbanken mit Paket A usw...

      Die Idee mit dem intervallbasierten Bereinigen ist auch ein guter Ansatz. Wobei auch hier eine Download-Funktion ala "downloadFile(this, "Lieferschein.pdf")" oder ähnlich ein Traum wäre... du musst da ja momentan auch über Make oder Node Red gehen denke ich, oder?

      • B²KC Klinger GmbH
      • Bjorn_Klinger
      • vor 7 Monaten
      • Gemeldet - anzeigen

       
      Wie funktioniert dieses Vorgehen? Leider bin ich nicht mit so umfassenden Programmierkenntnissen ausgestattet, dass ich aus deiner Beschreibung auf einen Lösungsansatz komme. Würdest Du es detaillierter erläutern? Evtl. sogar Code preisgeben?

      Machst Du es mit einem Klick je Datensatz? Das wäre ja sehr mühselig wenn es bei der Anzahl in die hunderte oder gar tausende geht.

      Oder lassen sich z.B. alle Bilder (je ein Datensatz in separater Tabelle „Bilder") von einem verknüpften Datensatz (z.B. Projekt in eine separater Tabelle „ Projekte“) aus speichern und löschen?

      Wie funktioniert das automatische Hochladen bei öffnen des Datensatzes?

      Vielen Dank im Voraus!   LG, Björn

      • Icarus_Ralf_Becker
      • vor 7 Monaten
      • Gemeldet - anzeigen

       Hallo Björn, wenn ich meinen Post jetzt im Nachgang lese, war er möglicherweise missverständlich und ich muss wie folgt eingrenzen: bei den Anhängen in meiner Anwendung handelt es sich ausschließlich um PDF-Drucks der jeweiligen Datensätze und keine sonstigen Dateitypen oder hochgeladene Dateien.

      Ich löse das wie folgt:

      (1) In einer zentralen Tabelle "Einstellungen" wird mit einem Zahlenfeld die Anzahl an Tagen festgelegt, wie lange die Anhänge vorgehalten werden.

      (2) Im onOpen-Trigger der DB steht u. a. folgendes Skript zum Identifizieren und Löschen der Anhänge, hier bspw. für Rechnungen:

      "
      /automatische Löschung von Anhängen/";
                  let mykey := my_settings.'API-Key';
                  let myteam := teamId();
                  let mydb := databaseId();
                  let mytableId_1 := tableId("Rechnungen");
                  let my_deathline := my_settings.'Datensatzanhänge vorhalten für';
                  "
                      / Rechnungsanhänge entfernen/";
                  let my_bill_records_1 := (select Rechnungen)[today() - my_deathline > 'Erstellt am' and cnt(files(this)) != 0];
                  if cnt(my_bill_records_1) > 0 then
                      let my_dialog := dialog("Achtung", "Die PDF-Dateianhänge aus insgesamt " + cnt(my_bill_records_1) +
                          " Datensätzen älter als " +
                          my_deathline +
                          " Tagen werden vorübergehend gelöscht, um Speicherplatz zu sparen. Die PDFs können jederzeit durch die Druckfunktion wieder hergestellt werden. Löschvorgang starten?", ["Ja", "Nein"]);
                      if my_dialog = "Ja" then
                          let my_counter := 0;
                          "/
              Rechnungen/";
                          for i in my_bill_records_1 do
                              let my_array := split(text(files(i)), ",");
                              for j in my_array do
                                  let filename := item(split(j, "/"), 1);
                                  let response := do as server
                                          http("DELETE", "https://api.ninox.com/v1/teams/" + myteam + "/databases/" + mydb + "/tables/" +
                                          mytableId_1 +
                                          "/records/" +
                                          i.Nr +
                                          "/files/" +
                                          filename, {
                                              Authorization: "Bearer " + mykey
                                          }, null)
                                      end;
                                  my_counter := my_counter + 1;
                                  alert(my_counter + " Dateien gelöscht")
                              end
                          end;
                          alert(my_counter + " Dateien gelöscht ✅")
                      end
                  end;
      

      (3) Im Karteireiter-Trigger jedes Rechnungsdatensatzes steht vor der Öffnung (Skript ist hier eingekürzt dargestellt):

      "
      /Anlagen wiederherstellen, wenn diese automatisch nach Fristablauf gelöscht wurden/";
      if cnt(files(this)) = 0 and Rechnungsnummer != null then
          "
          / Rechnungs-PDF erstellen und als Anlage speichern /";
          let layout := null;
          if 'Sprünge' != null then
              if Rechnungspositionen = null then
                  layout := "1"
              else
                  layout := "3"
              end
          else
              layout := "2"
          end;
          importFile(this, printAndSaveRecord(this, layout), "Rechnung-" + Rechnungsnummer + ".pdf");
          Beleg := text("Rechnung-" + Rechnungsnummer + ".pdf")
      end;
      
    • UweG
    • vor 11 Monaten
    • Gemeldet - anzeigen

    Wenn man momentan mit seinen Dateien DSGVO konform arbeiten muss, um nicht in Abmahnfallen zu tappen, verbleiben nur selbst gehostete Lösungen.
    Bspw. Nextcloud als Datenspeicher und n8n als Transferprogramm und für weitere externe Anbindungen falls notwendig. Beides selbst gehostet und man ist auf der sicheren Seite mit seinen Dateien.

    • Michi.1
    • vor 11 Monaten
    • Gemeldet - anzeigen

    Intern buchbarer Speicher wäre echt schön. Ich habe jetzt die Dateien auf Cloudinary ausgelagert, welche ich zwar benötige, jedoch im Falle eines Serverproblems bei Cloudinary weiter arbeiten kann. Was heißt, die lebensnotwendigen bleiben intern gespeichert. Cloudinary ist auch super schnell (Schneller als Ninox) im Bereitstellen der sharelinks. Jedoch ist auch hier das Problem, was ist, wenn der Free Account ausgeschöpft ist? Dann wird es auch hier unangenehm teuer. Die Kurve zeigt ja leider immer nur in eine richtung... nach oben.

    • Andreas_Kessler
    • vor 8 Monaten
    • Gemeldet - anzeigen

    Meine etwas urchige Lösung dazu ist

    1. Pdf's die ich in Ninox zum versenden per Email erstelle, werden nach dem Versenden sogleich vom senden Script gelöscht, nachdem das Script mir eine Unixtaugliche serveradresse für meinen Privaten Server erstellthat.

    - Das pdf Speichere ich in einem Lokalen Ordner, entweder einzeln aus dem gesendetem Mail, oder per Mailextract Batch (Thunderbird Plugin) Mehrere Mailanhänge gleichzeitig. In Thunderbird habe ich dazu einen Ordner der per Filter alle von Ninox gesendeten mails sammelt (die sind dann also auch auf dem Mailserver gespeichert)

    2. Dokumente, Fotos etc, Speichere ich lokal im gleichen Ordner wie die Mailanhänge. Auf meinem Rechner läuft immer ein ftp Programm (fileZilla oder Gftp), dass die Dateien laufend auf meinen Server lädt. Da muss ich aber den Dateinamen in Ninox angeben (textfeld) und mit meinem Script (button) url erstellen den Link zur Datei erstellen lassen. Per Button lade ich die Datei dann zum anzeigen ebenso wieder von meinem Server.

    Wichtig ist dabei einen Unixkonformen Dateinamen zu generieren ohne Leerschläge, Umlaute oder sonderzeichen.

    Geht für mich ganz gut, ausser bei der Pflanzendatenbank, dort habe ich aber Pflanzenbilder, Karten generiert die alle unter 100kb haben, zusammen 2mb, für die Bildschirmdarstellung optimiert. so habe ich gut 300 Pflanzenportraits als jpg dateien in Ninox drin, noch aus alten Filemakerzeiten wo nur 2mb Speicher erlaubt waren ;-).

    • Icarus_Ralf_Becker
    • vor 8 Monaten
    • Gemeldet - anzeigen

    interessanter Ansatz. Allerdings bleibe ich  bei meiner Bewertung, dass Ninox dringend das Speicherplatzproblem lösen muss, wenn das Produkt nachhaltig konkurrenzfähig werden o. bleiben soll. Speicherplatz ist bei einer DBaaS ein Hygienefaktor, der durch Ninox bei halbwegs professioneller Anwendung nicht hinreichend befriedigt wird. Die Frage ist eben nur, zu welchem Zeitpunkt das dem neuen Nutzer bewußt wird. Speicherplatz darf künftig überhaupt kein Thema mehr sein, weil er m. M. n. auch in der Kostenstruktur den geringsten Faktor darstellt. Um Auswüchse zu vermeiden, kann man ja gerne max. Dateigrößen definieren und eine Maximalanzahl an Anhängen pro Datenbank. Dann würde im Übrigen das immer noch fehlende Speicherplatzmanagement kein Problem für Kunden darstellen. Sowas nennt man, glaube ich, "zwei Fliegen mit einer Klappe geschlagen". In jedem Fall freut sich nur einer über die völlig unzeitgemäße Volumenbegrenzungen von 2 bzw. 5GB oder komplizierte Workarounds zum Auslagern der Dateianhänge in einer NoCode/LowCode-Plattform: die Konkurrenz.

Content aside

  • 4 „Gefällt mir“ Klicks
  • vor 7 MonatenZuletzt aktiv
  • 41Antworten
  • 1772Ansichten
  • 18 Folge bereits