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

[Ghostwalker]

Von Oracle her kenn ich da nur die "partitioned Tables", da kann man sowas autoatisch machen (Soweit ich weiß, kann das auch MS-SQL).

Denkansätze:

a) Backup-Strategie

Wenn du jedesmal ein Fullbackup machst (also die komplette DB), würd ich erstmal auf inkrementelles Backup umstellen. Dabei erstellst du nur einmalig ein vollständiges Backup, danach werden nur noch die Änderungen gespeichert.


b) Dokument auslagern

Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.


Gruß

Uwe

[IBExpert]

Zitat von Ghostwalker:

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

[tsteinmaurer]

Hallo Holger,

Zitat:

Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren ...

Ja, wenn man dann selbst (sehr) viel herumbaut, was du ja mit deiner 9 Punkteliste gezeigt hast. Wollte Gerd nur vermitteln, dass man hier "Out-Of-The Box" wenig Wunder erwarten kann bzw. dass es Cross-DB gewisse Einschränkungen gibt und z.b. kein Löschen in deiner Stammdaten-DB unterbunden wird (z.B. Adresse, Rechnung, Kunde etc.), obwohl dieser Datensatz in der Archiv-DB noch referenziert wird.

LG

[bernau]

Hallo zusammen,


danke erst einmal für eure Antworten.

Auslagern der Dokumente in einzelne Dateien ins Filesystem kommt aus verschiedenen Gründen nicht in Frage.

* Ich möchte keinen Zugriff mehr vom Programm auf das Dateisystem. Ein reiner IP-Zugriff ist für mich aus Gründen der Datensicherheit ein Totschlagargument geworden.

* Bei einer großen Anzahl (>50.000) von Dateien in einem Verzeichnis habe ich schon öfter Probleme mit Performance des Dateisystem bekommen. Habe das gelöst, in dem ich max 1000 Dateien in viele Unterverzeichnis gelegt habe. Aber auch das ist nicht das gelbe vom Ei.


Die angesprochene Funktion "out of the Box" wäre schön. Deshalb habe ich ja gefragt. Ist aber für mich nicht ein Ausschlusskriterium. Wenn ich mich für eine DB entschieden habe, werde ich wohl damit bis zu meiner Rente arbeiten. Eine Umstellung meiner Software auf die neue DB würde auch > 6 Monate in Anspruch nehmen. Bis dahin werde ich mich wohl gut in die neue DB eingearbeitet haben. Aber wenn es "out of the Box" gehen würde, dann wäre das natürlich angenehm.


@Holger: Ich werde mir mal am Mittwoch deinen Stammtisch anschauen. Freue mich schon drauf.

[IBExpert]

ich hab dann schon mal dieses Themenpaket für Mittwoch vorgesehen

-Dateien und Blobs in der Firebird Datenbank
-Verteilen auf verschiedene Datenbanken, Readonly Jahresarchive
-Zugriff über execute statement on external, transaktionssicherheit
-kurze Codebeispiele für lazarus/delphi und Einblick in reale Projekte
-Tips und Tricks für Dateivearbeitung in der Datenbank
-eingescannte Dokumente und serverside OCR
-EMails abrufen, verabeiten, preview erzeugen und anhänge extrahieren

Wird ja wie immer auch auf Video ausgezeichnet, aber direkte Fragemöglichkeiten und Antworten gibt es dann zwischen 17 und 19 Uhr

[bernau]

Zitat von IBExpert:

ich hab dann schon mal dieses Themenpaket für Mittwoch vorgesehen

Cool.

[olaf]

Mit postgresql läßt sich Deine Anforderung über Partionen einfach lösen.

[himitsu]

Jupp, ich hatte auch erst an sowas wie in Postgres gedacht.
Man kann in so manchem DBMS derartiges anlegen, wo nach gewissen Regeln eine Tabelle aufgeteilt wird.
https://www.postgresql.org/docs/10/d...titioning.html

Das SELECT/INSERT/UPDATE/DELETE geht dann transparent immer nur auf eine Tabelle, deren Inhalt aber auf unterschiedliche Dateien verteilt wird.

Auch nett für ein Backup: z.B. nach Jahr/Monat getrennt, verändern sich die alten Partitionen nicht mehr, außer man löscht/editiert was, also aktuellere Datensätze haben keinen/selten einen Einfluß auf uralte Daten-Dateien.

Zitat von bernau:

Ich möchte keinen Zugriff mehr vom Programm auf das Dateisystem. Ein reiner IP-Zugriff ist für mich aus Gründen der Datensicherheit ein Totschlagargument geworden.

Auch das ist bei vielen DBMS möglich, selbst wenn man hier über den DB-Server geht.
Oftmals ist es möglich über die DB auf das Dateisystem im Server zuzugreifen. (unter gewissen sicherheitsbedingten Restriktionen)

So kann man auch die Daten/BLOBs durch die DB getrennt in ein/mehrere Verzeichnisse speichern, die Metadaten in einer Tabelle ablegen und dann beim SELECT den Dateiinhalt als BLOB mit anjoinen oder via SP nachladen.
https://www.postgresql.org/docs/current/lo-funcs.html
https://www.postgresql.org/docs/current/adminpack.html

[taveuni]

Zitat von IBExpert:

Zitat von Ghostwalker:

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

Verstehe ich nicht. Meiner Meinung nach sollte eine moderne Client/Server Anwendung sowieso niemals einem Client direkten Zugriff auf Daten ermöglichen. Weder auf eine Datenbank noch auf serverseitig gespeicherte Dateien. Moderne IT Umgebungen lassen dass sowieso seit Jahren bei uns nicht mehr zu. Es gibt genau eine TCP Verbindung von den Clients zum Server. Demzufolge ist dann der Server exklusiv für die Datenhaltung zuständig. In unserem Fall können dies auch mehrere Terrabytes umfassende Videodaten (=Dateien) sein. Diese in Blobs in einer Datenbank zu speichern wird dann eher schwierig.

[IBExpert]

Nur um mal eben auf den Boden der Tatsachen zu kommen und eingeworfene Buzzwords zu vermeiden:
Welche mehrere Terabyte große Videodateien speichert Ihr denn irgendwo im Filesystem oder ruft
die on Demand über eine tcp/ip verbindung von wo nach wo ab?

Wir haben diverse Kunden im Medizinumfeld, von denen viele Bilddateien und teilweise auch Videos
oft auch nur verlustfrei komprimiert in blobs landen, ein terabyte in einem Datensatz hat dabei
aber noch niemand erreicht. Und ein CD, die ich nach einer MRT Untersuchung für meinen Facharzt
mitbekam, hatte nicht mal 200MB an Daten auf dem Datenträger ... , passt also locker in blobs,
insbesondere weil die dutzenden einzeldateien noch wesentlich kleiner waren. Nach meinem
Kenntnisstand sind MRT Daten schon ziemlich detailliert, aber wer weiß, vielleicht gibt es
ja aktuell Youtube Livestreams in 4k bei der Darmspiegelung ....

Videos sind genau wie Bilder zwar groß, aber eigentlich auch extrem langweilig, weil sich
die im Gegensatz zu zum Beispiel industrielle 3D CAD Zeichnungsdateien nicht mal eben
nur an einer Stelle minimal ändern, dadurch aber komplett neu gebraucht werden. Versionierung
von Dateien, Reproduzierbarkeit von Vorgängerversionen, usw. Den 3D Viewer interessiert
es nicht, das deine Daten irgendwo per tcp/ip stream kommen könnte, ob das modern ist oder
nicht, dafür werden auch aus caching gründen gerne und oft lokale Dateien benutzt.

Was "moderne IT Anwendungen" sind, weiss ich nicht, aber generelle Regeln, das die irgendwas
immer irgendwie machen, halte ich für gewagt. Der Mehrwert durch solche Anmerkungen ist also
begrenzt.