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
-
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
-
Über die Ninox API kann man auch das Bild endgültig in Ninox löschen.
-
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.
-
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. -
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.
-
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 ;-).
-
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