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

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

[bernau]

Zitat von olaf:

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

Ich werde mir mal die Doku dazu anschauen. Hast du ein Stichwort, nach dem ich suchen kann?

[hoika]

Hallo,
Stichwort
"PostgreSQL - Partionen"

Eine Partition ist vereinfacht ein separate Datei (jaja, sehr vereinfacht).
Man kann einer Tabelle eine separate Partition zuordnen, aber auch einen Teilbereich einer Tabelle
(ähnlich wie ein View, nur dass die Daten wirklich separat gespeichert werden).

Links:
https://severalnines.com/database-bl...ata-postgresql
https://www.postgresql.org/docs/10/d...titioning.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]

Partitionierung ist für Firebird 5 in Arbeit, löst aber bei denen die es schon haben keineswegs das
Problem, das Teile der DB nach eigener Organisationsvorgabe in readonly Teile ausgelagert werden
können und damit gar nicht mehr in Backups gesichert werden müssen. Wenn am Ende eine DB
1TB hat und du eine Sicherung machen musst, ist es egal, ob die Partitioniert ist oder
nicht. In die Sicherung muss die komplett rein, es sei denn, du willst dich mit den
Varianten von partieller Sicherung herumärgern, bei denen du auch alle Zwischenstände
vorhalten muss, was dazu führen kann, das deine Sicherung deiner 1TB DB am Ende sogar
weit mehr als 1TB an Platz braucht.

Nur weil eine Plattform deklarative Möglichkeiten hat, gewisse Problemstellungen zu lösen,
wage ich zu behaupten, das die begrenzten Möglichkeiten innerhalb dieser deklarativen
Variante keineswegs die Vorteile aufwiegen, das selber umzusetzen und vollständig
zu verstehen und erweitern zu können.

Konkretes Beispiel: Das Replikationsprojekt mit mehr als 200 Standorten wäre hoffnungslos
gescheitert an mehreren Faktoren, wenn wir uns dabei auf vorhandene Replikationslösungen
verlassen hätten, weil die deklarative Variante zwar das kann, wofür die designt wurde,
die realen Anforderungen aber in verschiedenen Schritten immer weiter gingen und wir
dann dauernd hätten sagen müssen, geht nicht ...

Ist vielleicht auch eine Mentalitätsfrage, ob man ähnlich wie bei Kompnenten die fertige
eierlegende Wollmilchsau sucht oder konkret hinterfragt, welcher Aufwand ist wirklich
erforderlich, um das zu machen, was man wirklich braucht.

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

[hoika]

Hallo,
ja, es gibt keinen "so geht das immer"-Weg.

Alles in die DB:
- alles an einem Platz
- Backup dauert sehr lange

Dokumente auslagern
- DB + Metadaten der Dokumente (Pfad)
- Backup der DB und Smart-Backup der Dokumente (alias Sync z.B. via RoboCopy)


Beides hat Vorteile und Nachteile.

[Ghostwalker]

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.

a) Das ein Client direkten Zugriff auf die Dateien braucht, wär mir neu.

b) Ja...wenn der Administrator Scheiß baut, kann die beste Software nix mehr retten (sprich wenn der die Dateien löscht oder verschiebt).

c) Ein Dateisystem kann genauso skalierbar sein wie jede Datenbank. Wie das bei MS liezenztechnisch aussieht kann ich nicht sagen. Bisher kenn ich nur Systeme
die sowas auf Unix/Linux Ebene machen.

Gruß Uwe