Daten einer Datenbank automatisch in eine neu zu erstellende Datenbank verschieben.

[Ghostwalker]

@bernau

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird.

@IBExpert
Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes). Da seh ich natürlich den Vorteil einer DB, was den Komfort angeht. Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt (Bsp. GitHub).

Aber egal, es wird denk ich nicht DIE Lösung geben, sondern schlicht mehrere Möglichkeiten. Mir ging es auch nur darum einige Denkansätze zu liefern.

[mkinzler]

Zitat:

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird.

Dann wird das Ganze aber wieder komplizierter. Man würde dann ja wieder einen extra Dienst o.ä. benötigen oder eine Erweiterung des Servers (UDF, ...).

Zitat:

Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes).

Was dann eine weitere Datenbank wäre, welche aber ausserhalb der Kontrolle wäre (OS).

Zitat:

Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt

Löst aber das Grundproblem hier nicht. Dann hat man wieder alles in einer Datei.

[bernau]

Zitat von Ghostwalker:

@bernau

Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird.

Natürlich nicht auf dem Client. Aber wenn die Dateien auf ein Laufwerks-Share des Fileservers landen, dann hast du ja trotzdem Zugriff auf die Dateien. Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert. Dann doch lieber in die Datenbank. Für den Client ist der Zugriff dann einfacher.

[himitsu]

Zitat von bernau:

Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert.

Jupp, wir hatten schon einen Dienst, aktuell mit DataSnap, der seit einer ganzen Weile auch die Dateien des DMS zum Client bringt, welche in der DB verwaltet werden.

Also ja, eine Netzwerkfreigabe (Dateiserver) geht, sowie auch andere Dinge ala Samba/FTP/WebDAV,
auch kann man manuell mit INDY spielen oder einen höheren FunktionsServer (ala DataSnap/REST/SOAP/...) benutzen
oder eben auch eventuelle Dateifunktionen des Datenbank-Servers.

Sowoe eben doch die Daten als BLOBs direkt in der Datenbank,
automatisch oder manuell aufgeteilt, wenn es zuviel für eine Datenbank/Datei ist.


Irgendein Server/Service muß also am anderen Ende hängen und was man nun benutzt, das ist kann jeder selbst entscheiden.
Vorhandene Dienste sind am Einfachsten, weil schon da und nur benutzt werden müssen, oder andere Dienste, welche man erst aktivieren/freigeben, installieren oder gar erst selber bauen muß.

[jobo]

Zitat von bernau:

Zitat von Ghostwalker:

@bernau
Ja, die Dokumente werden ins Filesystem ausgelagert, aber doch nicht auf dem Client, sondern logischerweise auf dem Server (dort ist ja auch die DB). Der Server liefert dann die Dateiinhalte aus wenn das ganze benötigt wird.

Natürlich nicht auf dem Client. Aber wenn die Dateien auf ein Laufwerks-Share des Fileservers landen, dann hast du ja trotzdem Zugriff auf die Dateien. Alternativ müsste man wieder ein Serverprogramm parallel zu Firebird haben, welches die Dateien ausliefert. Dann doch lieber in die Datenbank. Für den Client ist der Zugriff dann einfacher.

Das geht auch anders und bringt dann ja erst den Nutzen. Eine Dateiupload SP mit der Steuermöglichkeit, Dateiablage in FS/DB/BOTH. Die DB schreibt die Datei bei entsprechender Konfiguration ins lokale Dateisystem und niemand kommt da sonst dran.
Also zur Klarheit: ein DB Server benötigt keine Share Laufwerke, um dort Dateien abzulegen oder anzunehmen. Das geht über normale Insert/Update/Select oder eleganter über SP.

Zitat von Ghostwalker:

Wenn ich IN den Dateien etwas suche, dann schenkt sich eine DB warscheinlich nicht viel mit einem Filesystem, was die Geschwindigkeit betrifft (also nach einem Teil eines BLOB-Feldes). Da seh ich natürlich den Vorteil einer DB, was den Komfort angeht. Allerdings würd ich bei den von dir beschriebenen Datenmengen auch keine Relationale Datenbank nehmen, sondern eher in Richtung Mongo-DB mit Elastic Search guggen, da diese Kombination auf so etwas abzielt (Bsp. GitHub).

Suche in Dateien artet natürlich beliebig aus ohne Formateinschränkung. DB Seitig würde man hier wohl Volltext Indizierung einsetzen, sodass die eigentliche Datei gar nicht angepackt wird zur Suche. Setzt voraus, dass man für die Dokumente automatisierte Textextraktion verfügbar hat.
MongoDB klingt nett und modern, würde ich aber ohne Kenntnis des Gesamtbedarfs unter keinen Umständen empfehlen. Um es mal ganz einfach zu sagen: für Mongo sprechen eigentlich nur sehr spezielle Datensituationen und vielleicht Geschwindigkeit bei sehr großen Datenmengen. Das eine ist hier nicht bekannt, große Datenmengen schließe ich nach den jetzigen Angaben aus.
Ich meine :“MongoDB kann jetzt auch Transaktionen! (Aber benutzt es besser nicht)“ sagt schon eine Menge. Oder die Anzahl an MongoDB Threads hier und ihre Natur (wie neulich).

Ich finde, eine DB Empfehlung ist bei der derzeitigen Beschreibung schwierig, weil es nur um das eine Problem geht und das nicht sehr typische Datenbankanforderungen stellt.