|
Datenbank: Firebird • Version: 3.0 • Zugriff über: UniDAC
Bilder in (Firebird-)Datenbank speichern
Hallo,
wir wollen Bilder in einer Firebird-Datenbank speichern. Bislang wird über eine Dateifreigabe darauf zugegriffen. In den "HomeOffice-Seminaren" dieses Frühjahr von Holger Klemt wurde schön beschrieben, wie man das macht. Die technische Seite sollte also weniger das Problem sein. Was mir eher Sorgen macht, ist die Datenmenge: es sind ca. 170.000 JPEG-Bilder (Tendenz: steigend) mit einer Gesamtgröße von 24 GB. Was sind so die Erfahrungswerte bei euch - kann ich das alles in eine einzelne FDB-Datei packen oder muss ich das aufteilen? |
AW: Bilder in (Firebird-)Datenbank speichern
Sollte kein Problem sein.
|
AW: Bilder in (Firebird-)Datenbank speichern
Moin...:P
Zitat:
PS: Denkst du auch an den Entwickler? Wenn der Entwickler die Datenbankstruktur ändern muß, muß er beim Testen der neuen Statements, es geht nie beim ersten Mal glatt, immer die 24GB+ Datenbank wiederherstellen. :zwinker: Der kann sich dann den halben Tag Kaffee holen... |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
Mit der großen Datenbank habe ich auch so meine Probleme und in folgendem Thread gefragt, ob man ggf. auslagern kann  https://www.delphipraxis.net/204179-...rschieben.htmlDarauf hin hat Holger Klemt ein echt ansehnliches Video-Tutorial auf Youtube gestellt. Dabei werden Daten in eine weitere Datei ausgelagert, die dann readonly ist. Diese muss man also dann nicht mehr permanent sichern. |
AW: Bilder in (Firebird-)Datenbank speichern
die größte db mit der ich aktuell regelmäßig zu tun hab, hat mit bildern und pdfs derzeit ca 600GB
über alle datenbanken hinweg sind das mehr als 2TB mein Tip (kam glaub ich auch im Video): beim Zugriff auf die Blob Inhalte die Client Anwendung nicht direkt auf die Tabelle zugreifen lassen, sondern über den Umweg einer SP, die einen blob als Rückgabe parameter hat und eine id o.ä. als eingabeparameter, weil du dann die clientseitige Implementation immer nur ein mal machen musst, serverseitig aber die sp so umbauen kannst, das die per execute statement on external auch auf andere (zB Read Only Archiv) Datenbanken sogar auf anderen Servern zugreifen kannst, auch wenn deine client app davon gar nichts weiss, muss die ja auch nicht. |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
Zur Klarstellung: Das sind nicht unsere Bilder. Die meisten Kunden haben auch deutlich weniger davon, etwas 10-20% der Menge. Aber ein Kunde hat halt Massen davon. Den Nachteil sehe ich eher darin, nicht mal eben die Bilder außerhalb der Software anschauen zu können. Wir haben Kunden, die nach Vorgängen suchen, indem sie den Bilderordner im Total Commander öffnen, nach Datum sortieren, und dann alle Bilder vom Zeitraum anschauen, ob da Bilder des gesuchten Vorgangs dabei sind... Ich hatte schon überlegt, mit einem Listview einen Explorer zu faken, der dann die Bilder in der Datenbank so anzeigt, als seien diese in einem Ordner. Stelle mir das aber kompliziert vor. |
AW: Bilder in (Firebird-)Datenbank speichern
Die Ansicht mal eben nach Datum sortieren, wenn es nur ein Pfad ist, sollte im Explorer im Filesystem kein them sein, selbst nicht mit der im Explorer vorhandenen Preview Ansicht.
Aber mach das einfach mal testweise mit wahlweise einer Millionen bilder in einem pfad oder auch in Unterpfaden, die geschwindigkeit vom filesystem gerade auf windows wird bei großen Datenmengen (im sinne von anzahl dateien) recht gemütlich, um das mal freundlich zu sagen. Und von einem Zugriff auf die gleiche Ordnerstruktur über ein Netzwerk rede ich dabei noch gar nicht. Es hindert dich ja auch keiner daran, in einem Filecache auf der Platte die native files abzulegen, das mach ich bei jeder zu öffnenden pdf Datei auch so, weil ich keine Lust hab, mit irgendwelchen Memory Streams halb funktionierende Komponenten und DLLs zu füttern, weil ich dafür ja sumatra als eigene exe einbinde, TImages aber direkt aus dem blob in die eigene Applikation zu ziehen und dort dann dazustellen, ist für png und jpg auch kein wirkliches Problem, aber erzeuge mal testweise auf einer Scrollbox zB 2000 TImages deiner Wahl und lade in alle ein anderes Bild aus dem Filesystem oder aus dem Datenbankblob. Bei png weiss ich ganz sicher, das das schnell mal 10-20 Sekunden dauert auch wenn nur ein Bruchteil davon sichtbar ist oder kleiner skaliert wird. Die Zeit verbrät aber nicht die lese/schreibe Operation sondern das decoding der Bilder. Da gibt es schnellere und langsamere TImage Varianten, aber zaubern können die alle nicht. Wenn du aber zB auf deinem Screen 10 Bilder nebeneinander darstellst und 5 Untereinander und eine unabhängige Scrollbar daneben baust, mit der man navigieren kann, wird das um längen schneller und dafür dann Bild 9950-10000 zu holen geht per sql befehl mit select first 50 skip 9950 * from ... und es fallen viele Overhead Operationen komplett weg, viele Webseiten arbeien übrigens ähnlich und auch da wird nix geholt was nicht explizit dargestellt werden soll. Bei großen Datenmengen im Sinne von Anzahl Dateien und Bildern im Filesystem zu bleiben halte ich für eine Sackgasse, unter der gerade deinen Anwender mit großen Datenmenge leider werden, ich würde das niemals so machen. |
AW: Bilder in (Firebird-)Datenbank speichern
ach ja, und bezüglich der Suche nach Datum, unser größter Kunde mit so einer pdf/png Archiv DB kann auch auf allen Dokumenten nicht nur nach dem Datum suchen oder einschränken, sondern hat in einem extra blob die erkannte OCR Volltext Inhalte des Dokuments bei scans oder bei pdfs das was als Text im pdf war, das hat sich insbesondere bei technischen Zeichnungen schon bewährt, weil oft in der Zeichnung schon Begriffe stehen, wo man was ähnliches sucht, geht in google ähnlicher Syntax, die aber die db auseinander nimmt.
Nur nach datum einschränken, dann würden die mir den Kopf abreissen .... |
AW: Bilder in (Firebird-)Datenbank speichern
In der DB finde ich das auch nicht so toll. Eine DB ist halt kein Fileserver.
Bei dem Speicherverfahren von FB weiß ich nicht, ob es sich negativ bemerkbar macht. Aber in einem System, das auf Point In Time recovery ausgelegt ist, entstünden viele Änderungsdaten, die alle gemanaged werden müssten. Ich habe mal ein System gebaut, wo die Datein (egal was) auch per SP geladen wurden. Auf dem Server wurde dann je nach Einstellung, Größe eine Speicherung in das Dateisystem vorgenommen. Wahrscheinlich etwas ähnlich zu dem was ibexpert geschrieben hat. Die Datenbank hat verwaltet, wo die Dateien liegen und Metadaten gespeichert. Auf die Art hat man Sicherheit, Flexibilität und Ordnung mit wenig Ressourcenverbrauch. |
AW: Bilder in (Firebird-)Datenbank speichern
Wenn einem die Datenbank-Dateien zu groß werden, dann könnte man die Tabellen auch noch partitionieren (aufteilen).
Dem Plattenspeicher selber ist es ja egal, ob die Dateien einzeln oder in einer großen DB rumliegen. (sind ja insgesamt gleich viele Bytes) Wir hatten früher auch mal alle Dateien als Blob in der DB und jetzt liegen sie im Dateisystem. Hat aber vorallem mit Gründen des Backups und einer revisionssicheren Speicherung (Unterstützung für ein WORM-Laufwerk) zu tun. Und die Dateien werden hier in der DB-Verwaltet, zusätzlich mit HASH, um die Datenintegrität prüfen zu können, und dann werden sie über DataSnap vom Server rausgegeben, aber da geht auch jede andere Client/Server-Architektur. In einigen DBMS kann man auch von der DB auf das Dateisystem des Servers zugreifen. Rein theoretisch könnte man die Dateien dann in einer Tabelle verwalten und die Dateiinhalte statt in Blobs als einzelne Dateien speichern, aber sie dennoch über die DB-Verbindung speichern und abrufen, also z.B. beim Abruf der Tabelle als Blob anjoinen. |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
und dutzende Clients in Netzwerk da auf die Dateinamen und Attribute zugreifen müssen, weil die da mit dem Explorer darauf arbeiten, entsteht dadurch schon mal eine Menge reiner I/O traffic und was in vielen Fällen noch schlimmer ist, ein freundlicher Trojaner deiner Wahl räumt die Inhalte da gerne mal auf, egal auf welchem der angeschlossenen Systeme das über die Dateifreigabe dann ausgelöst hat. Wenn es so was wie Filesystemtrigger BeforeUpdate geben würde, könntest du immer noch den alten Inhalt sichern bevor der überschrieben wird, im Netzwerk war es das dann oft mit dem brauchbaren Inhalt der Datei ... Ein Trojaner, der sich in der Datenbank anmeldet und dann alles löscht, kenn ich so nicht, falls das doch mal passiert, nennt man den, der das veranlasst hat, zwar vorne auch Tro aber das Wort geht hinten mit ttel weiter Weitere Aspekte dafür, so was in der DB zu machen: Echte Transaktionsfähigkeit, keine echten Limits was die Anzahl der Records betrifft, beliebige viele zusätzliche Attribute und Foreignkeys, Realtime Hot Backup ohne Trickersei wären schreibvorgänge weiterlaufen, uvm. Es muss aber jeder für sich bewerten, in kleinen Datenmengen ist der Mehraufwand gegenüber dem Filesystem vielleicht doch zu hoch, aber die Vorteile überwiegen bei großen Datenmenge erheblich. Daher gab es das aber auch ja von mir als Video, basiert auf Praxiserfahrungen ... |
AW: Bilder in (Firebird-)Datenbank speichern
Ja, das mit "einer" Transaktion wäre schon was Nettes.
Wir/Ich hatte schon ganz schön kämpfen müssen, um Dateien und deren Datensatz synchron zu halten, also beim speichern/löschen/ändern an einer Seite bei Problemem die andere Seite passend zu bekommen, z.B. beim Importieren kann es ja im Dateisystem (Schreibrechte oder fehlende Ordner/Freigaben), der Datenbank (Trigger) oder bei den Nutzerrechten im Client irgendwo was knallen und es wäre unschön, wenn dann die Datei oder der Datensatz halb zurück bleibt, wenn etwas der Anderen knallte. Das böse Microsoft baut grade die Transactionen wieder aus. :cry: Dateisystem und Registry Angeblich haben es zu wenige genutzt und ich war die letzten Jahre auch noch nicht dazu gekommen, wobei ich es auch erst vor "paar" Jahren fand. Nja, im NAS nitze ich Btrfs ... schnelle Snapshots, wo beim Schreibzugriff und Löschen die Dateien gesichert werden (CopyOnWrite) Btrfs im Windows ist leider nicht so super/sicher supported (da arbeitet praktisch nur Einer dran) und ReFS oder was es sonst noch so gibt. Aber Möglichkeiten gibt es Viele, um Dateien hinter einer Netzwerkfreigabe auch mit Schreibzugriffen schützen zu können, was direkt im Windows nicht so leicht möglich ist, aber auch lokal mit einer kleinen LinuxVM oder über einen angepassten Dateiserver, welcher die Dateien entsprechend revisioniert. |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
Der Schreib & Lese Zugriff erfolgt transparent über SQL, einerseits für die reine Datei, andererseits für klassische Attribute und Zusatzinfos über den Vorgang. Dahinter liegt eine SP die das in Tabelle speichert und die Datei ins FS aussteuert. Sicher, transaktional, bequem, universell, Ressourcen schonend. Durch die SP hat man wie schon genannt die Möglichkeit, auch weitere Nachverarbeitung, z.B. OCR + Volltextindizierung, what ever mit den Datein durchzuführen. Die späteren Recherchemöglichkeiten sind top und können bei Bedarf auch noch mit einer REST Schnittstelle ergänzt werden. Hier hätte man durch das Speichern im Server seitige Dateisystem auch die Möglichkeit, ganz einfach klassische Cacheverfahren einzusetzen, diverse Systeme dafür gibt es ja geschenkt. |
AW: Bilder in (Firebird-)Datenbank speichern
Im Filesystem sind aber mehrere beteiligt, daher bleibt es schwer
-jemand ändert mit der Anwendungssoftware eine Datei im Filesystem und sperrt diese dadurch, wer hat Kontrolle wann und wie die Sperre beendet ist? -jemand lädt per ftp eine datei in das filesystem und die Übertragung wird unterbrochen, datei ist also nur halb da ... -jemand verschiebt einen kompletten Ordner in einen anderen .. wie bekommst du technisch mit das es verschoben wurde und nicht delete und neue Dateien waren .... das sind nur Teile mit denen ich mich konkret beim Filesystem als Referenz rumärgern musste, es ist auch nicht entweder oder, aber bei uns hat sich bewährt, in der Datenbank ist die Referenz und für die meisten neuen Dateien gibt es definierte Importpfade und jobs im Hintergrund gleichen nach bestimmten Kriterien die Inhalte in der DB mit denen im Filesystem ab, bearbeitung dieser Dateien beginnt aber aus der eigenen Anwendung, die dann den Blobsinhalt lokal als Datei ablegt, dort die assoziierte Anwendung zu starten und sobald die datei nicht mehr zum Schreiben geöffnet ist, wird die neue Version mit der alten vergleichen und wenn es sich geändert hat als neuer Blob in der db abgelegt, der alte bleibt je nach Regelwerk in der DB für x Versionen in der DB oder wird in die Archiv db übertragen usw. Das passiert mit CAD Zeichnungsdateien, Office Dokumenten usw. Außer der sowie verfügbaren tcp/ip firebird verbindung zum Serer brauch ich nichts anderes, egal wo der Anwender arbeiten möchte, .... aber wie schon gesagt, ist mehraufwand als einfach nur Datei irgendwo liegen zu haben und nur den ort dieser Datei in die db zu packen, den Weg geh ich aber nicht, weil das am ende niemals konsistent sein wird |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
Und, ja, es ist auch schon vorgekommen, dass bei anderen Kunden Verschlüsselungstrojaner zugeschlagen haben und alle Bilder verschlüsselt. Die hatten glücklicherweise ein einigermaßen aktuelles Backup. Bei Bildern in der Datenbank kann das aber gar nicht passieren (es sei denn, der DB "Server" ist einfach ein weiterer PC im Netzwerk, auf dem sich der Trojaner austoben kann). |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
|
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
"MACHINE LEARNING MIT CAI" in real benutzbare informationen umsetzen. Softwaregestützte Objekterkennung ist sicherlich spannend für Leute mit viel Zeit und Spaß an Verfahren der künstlichen Intelligenz, leider sind oft die Ergebnisse im praktischen Einsatz eher das Gegenteil sprich "Natürliche Dummheit"... |
AW: Bilder in (Firebird-)Datenbank speichern
Wie war das mit der KI, der man beibrachte teure von billigen Autos zu unterscheiden?
Alles lief gut, bis auffiel, dass sie KI nicht die Autos unterschied, sonden nur gelernt hatte "teure" Autos wurden bei schönem Wetter fotografiert und waren sauber und dann kam mal eine saubere Schrottkiste bei Sonnenschein vorbei. MACHINE LEARNING kann viel, aber da es dir nicht sagen kann, warum es so entschied, weiß man auch nicht, ob es wirklich das macht, was es soll. :lol: Aber um "ähnliche" Bilder zu suchen, da sind dann kleine Fehler nicht ganz so schlimm, wenn es nur als Vorauswahl für den Menschen dient. |
AW: Bilder in (Firebird-)Datenbank speichern
Zitat:
Ich spreche von einem System, dass tatsächlich für Anwender nur als DB über IP:Port bzw. vergleichbare spezifische Verbindungsparameter erreichbar ist. Da macht niemand was per FTP (sowieso Horror), Explorer o.ä. Die Daten bzw. die Datein gelangen nur per SQL in das System. Das System ist ansonsten für Anwender nicht erreichbar. Falls doch, muss es ein Admin mit entsprechenden Rechten sein, mit expliziter Anmeldung als Admin und der hat dann einen fatalen Fehler begangen, wenn er versehentlich Dateien verschiebt oder überschreibt. Fatale Fehler als Admin können aber auch mit einer DB passieren. Auch dann gibt es diverse Möglichkeiten, damit umzugehen, angefangen bei eindeutigen Dateinamen, unabhängig von gespeicherten Pfadangaben und Links in der DB. Eine Verschiebung ist damit rekonstruierbar (ohne Backup), erst ein Löschen von Dateien oder das Ändern benötigt dann zur Rekonstruktion ein Filesystem Backup (Das dann für einzelne Dateien ausreichend ist). Ein gespeicherter Hash kann dabei jederzeit zur Prüfung genutzt werden. Dateizugriffsrechte können auch nur dem DB User gegeben werden. Ein Admin mit anderen Rechten muss dann schon waghalsige Sachen anstellen, um fremde Dateien zu zerstören. Warum man Windows mit Explorer und "versehentlich verschoben" als Server freiwillig verwendet, erschließt sich mir auch nicht. Aber das ist ein anderes Thema. Ich weiß, dass bei Kunden alles vorkommt was denkbar ist und noch mehr. Aber die Kunden sind auch diejenigen, die möglichst wenig für eine effiziente und sicher Implementierung ausgeben wollen. Man hat also auch da Argumente. Wer darauf besteht, Gigabyte oder Terrabyte an Daten auf w10 home zu managen, der soll es machen. Ich würde da für nichts garantieren. Es empfiehlt sich für den DB Server der Einsatz eines Linux Systems, am besten gleich headless- ohne grafischen "Explorer". Hier bekommt man auch diverse Filesysteme geschenkt, ein Dutzend gängige, aber "notfalls" auch Hunderte andere. Das geht auch mit Firebird. MS weiß sicher sehr genau, warum es unter der Haube WSL einführt und immer mehr Produkte für Linux anbietet. Wenn man so ein System implementiert, ist der Aufwand für versionierte Dateiverwaltung auch ziemlich gering. Es wird vomn System gar nicht mehr überschrieben, nur eingefügt. Verkürzt, man lässt die Update Implementierung weg. Gerade für Firebird Kenner dürften die Prinzipien dazu bekannt sein. |
AW: Bilder in (Firebird-)Datenbank speichern
Was sich mir persönlich an dem ganzen Filesystemgehampel nicht erschließt ist, warum ich mir die Mühe machen soll, etwas sicher und konsistent zu machen, wenn ich das in der DB automatisch habe.
Möchte ich Daten aufteilen, weil ich z. B. bestimmte Teile immer wieder auslagern möchte oder bestimmte Teile (Bilderarchiv z. B.) nicht ständig in der DB-Sicherung haben will, packe ich die in eine weitere Datenbank und greife immer nur über die Hauptdatenbank darauf zu. Da muss ich dann nichts mehr konsistent halten, das macht das System automatisch für mich. Dateinamen für Auslagerungen/Übergaben an andere Programme werden on the fly generiert. Da brauch ich mir nicht viel Gedanken machen. Und durch den dann fest vorgegebenen Weg kann mir auch kein anderer Entwickler das System versaubeuteln. Wie oft habe ich schon darüber gebrütet, warum irgendwelche Daten an total unsinnigen Stellen abgelegt waren. Oftmals hat es sich dann jemand mal wieder einfach gemacht und einfach so die Daten gespeichert, wie das die aufs Formular geklatschte Komponente eben von Hause aus macht. So hole ich die Daten von einem definierten Ort und stelle sie der Komponente/dem Fremdprogramm im erwarteten Format zur Verfügung und sichere die Daten danach in meiner Datenbank in meinem Format definiert wieder weg. Und keiner manipuliert dann noch was an meinen Daten rum. Hab da mal nen Admin gehabt, der war der Meinung TIFF-Dateien sind doof. Also hat er die alle in jpeg gewandelt. Die Darstellung im Programm funktionierte nach wie vor, aber OCR u. ä. machte die Grätsche. Da ist es dann auch Wurst, ob der Admin ja selbst schuld ist. Ich als Entwickler kriege das Problem erst mal auf den Tisch und muss mich im schlimmsten Fall für Umme drum kümmern. Daher ist meine Maxime: Alle Daten gehören für alles und jeden außer meiner eigenen Anwendung gesichert und verborgen. Just my 2Ct |
AW: Bilder in (Firebird-)Datenbank speichern
Deine Maxime mag für Dich gelten. Ich tendiere da eher zu der Äußerung von ibexpert, das muss von Fall zu Fall entschieden werden. (Bedeutet in der Praxis vielleicht auch eine vereinheitlichte, abgesprochene, abgestimmte, generalisierte Kompromisslösung.)
Deine Argumente verwischen auch meinen Kompromissvorschlag, das vielleicht Beste aus beiden Welten zu nehmen. Eine DB die Zugriffssicherheit und Fehlerschutz bietet und ein Dateisystem hinter der DB, das Schnelligkeit und Ressourceneffizienz bietet. Datenbanken mit all ihrem Luxus kommen mit dem Preis des Ressourcenverbrauchs (Platz, Zeit). Die Existenz von noSQL Systemen ist der lebende Beweis dafür. Das gilt auch und besonders beim Backup bzw. noch mehr bei der Restauration eines Backups, am deutlichsten bei einem Point in Time Recovery mit sequentiellem Einspielen der Änderungen. Ich kenne die Mechanismen von FB nicht sehr genau, aber bei anderen Systemen ist es meist so, dass parallel zu den Datenbankdaten auch Wiederherstellungsinformationen geschrieben werden, also eigentlich alles doppelt. Diese Daten werden dann wiederum beide durch Backupverfahren aufgegriffen. Administrative Maßnahmen wie eine Auslagerung von Dateidaten in eine weitere DB sind ebenfalls nicht ohne Fehlerpotential, besonders wenn es sich um manuelle Vorgänge handelt. Wie dabei ein Bildarchiv ständig Daten aufnehmen kann, aber nicht gesichert werden muss, erschließt sich anhand der Beschreibung auch nicht. Wenn das alles durchautomatisiert ist, meinetwegen auch okay. Einen hochperformanten Zugriff über FS und entsprechende Cachemechanismen habe ich damit immer noch nicht. Herausragende Fehl“administration“ ist im Einzelfall erschreckend, aber das ist schwerlich ein Argument für oder gegen etwas. Ich kann für jedes Verfahren irgendwelchen Irrsinn finden, der es beschädigt. Das ist natürlich alles relativ, aber Datenspeicherung per FS im direkten Zugriffsbereich des Endanwenders ist dagegen schon ziemlicher Horror. Ich habe jedenfalls in langer Praxis noch nicht erlebt, dass Administratoren eine Console öffnen, sich als DB User oder als root an einem Server einer fremden Software anmelden und Dateien verschieben, verändern oder löschen. Wenn durch ein SQL Interface Daten in einem Server unerreichbar verschwinden und dahinter geschützt im Dateisystem gespeichert werden, ist es gut. Im Fall, den ich beschrieben habe, kann ich für jede Datei wählen oder grob konfigurieren, wo am Ende gespeichert wird, wenn ich möchte auch beides, DB und FS. Das ist ja das Schöne, die Datenbank erlaubt einen sehr filigranen Umgang mit den hochgeladenen Daten. Das FS dahinter bringt einfach Speed und Raum für Nach- und Weiterverarbeitung mit einem riesigen Fundus an frei verfügbaren, fertigen Werkzeugen. Wer den puren Schutz in der DB vorzieht, kann das so machen, sollte die Nebeneffekten aber wenigstens kennen. |
AW: Bilder in (Firebird-)Datenbank speichern
@jobo: Es tut mir leid, wenn Du Dich persönlich von meinem Post angegangen fühltest.
Dies war nicht meine Absicht. Ich verwische allerdings keinesfalls Deine Argumente, ich gehe nur halt nicht wirklich mit ihnen mit. Den Tutorials von Holger habe ich im Allgemeinen nichts hinzuzufügen, alles weiter wären Feinheiten, die im Einzelfall besprochen werden müssen. Daher werde ich das hier jetzt nicht weiter aufrollen. Nur soviel: Der Ressourcenoverhead hält sich beim Firebird da sehr in Grenzen (eine richtige Konfiguration vorausgesetzt, die ich dem Kunden automatisch mitgebe) und an Geschwindigkeit steht der FB dem Filesystem da auch in nichts nach. |
AW: Bilder in (Firebird-)Datenbank speichern
Ich fühle mich nicht persönlich angegangen. Alles gut.
Hier gibt es nun genug Material, was Interessenten als Anregung für eigene Überlegungen und Experimente nutzen können. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 16:23 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz