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

[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.