Video in Firebird Datenbank

[MyRealName]

Segmentsize kann wichtig sein, da ja immer nur ein blob pro segment drin sein kann

Sind deine daten normalerweise 100-500 byte pro blob, lohnt sich eine Segmentgrösse von 8192 byte nicht, da verschwendest viel.
Aber wenn Du videos ablegst die mehrere Megabyte sind, dann nimm die segmentgrösse so hoch wie geht, weil dann brauch er nicht soviele Identifikatoren um pro blob festzulegen, wo das video verteilt gespeichert ist

[mkinzler]

Wieviele Videos passen den in 500 Bytes?

[haentschman]

Moin...
[mein Senf]
Wenn Bilder in die Datenbank gespeichert werden sollen erschallt ein Aufschrei, daß man so etwas nicht macht sondern nur den "Link" in die DB speichert. Mit Videos würde ich das, auf Grund der Größe, erst Recht machen.
Damit muß sich Windows mit der Ablage beschäftigen und nicht die DB muß MB an Daten schaufeln wo sie wichtigeres zu tun hat. Desweiteren dürfte das auch wesentlich pflegbarer sein.
[/mein Senf]

[Morphie]

Das musst du jetzt aber mal erklären.
Was sollte denn dagegen sprechen Binärdaten in der Datenbank abzulegen?

Stell dir mal eine Multi-User-Datenbank vor. Wie willst du da einen Pfad zur eigentlichen Datei speichern?
Soll jeder Client neben der Datenbankverbindung auch noch ein Netzlaufwerk oder eine UNC-Freigabe mit Schreib/Leserechten eingerichtet bekommen?
Das halte ich für viel schlimmer als eine Datenbank, die Binärdaten akzeptiert.

Oder was ist, wenn sich die Pfade mal ändern?

[Hansa]

Zitat von haentschman:

Moin...
[mein Senf]...Mit Videos würde ich das, auf Grund der Größe, erst Recht machen...

Wie rum jetzt ? Was gehört in die DB ? Das Video oder nur der Dateipfad ? Gegen ersteres spricht folgendes : Szenario Immobilienmakler. Der hat 1000 Immobilien und zu 500 hat er ein Video. Dauernd kommen neue Objekte hinzu. Bei Bedarf auch neue Videos. Jetzt macht der jeden Tag Datensicherung, damit die Adressen im Notfall immer aktuell bleiben. Muss der wirklich jeden Tag die Videos (die sich selten oder nie ändern) mitsichern ? Sagen wir 1 GB pro Video. Jeden Tag wären dann 500 GB mitzusichern (bei 1000 Adressen hätten die Nutzdaten wohl kaum mehr als 20 MB), sofern die Videos in der DB liegen. Werden die Videos separat gespeichert, dann kann man die ja auch ab und zu sichern. Der viel wichtigere "richtige" Datenbestand wäre dann täglich mit wesentlich geringerem Aufwand (an Zeit und Geld) zu sichern.

Anderes Beispiel : Produkt-Katalog, wo sich die Preise täglich ändern. Wann ändern sich da die Bilder ?

[mkinzler]

Für diesen Fall würde sich eher eine inkrementelle Sicherung anbieten. Die Speicherung des kompletten Inhalts hat auch den Vorteil, dass der Speichereort einfach geändert werden kann und das die Komplettsicherung deutlich schneller ist. Das Sicherheitsproblem von weiteren benötigten Freigaben wurde ja schon agesprochen.

[Perlsau]

Zitat von PhilmacFLy:

Ich nehm mithilfe des DSPack ein Video auf und möchte diese nun in der Datenbank ablegen. Ich dachte mir zuerst das ich die Datei in einen Stream lade und dann in ein Blob Feld ablege ...

Über Sinn & Unsinn, Videodateien in Datenbanken zu speichern, wurde schon viel geschrieben. Es kommt eben darauf an, wie viele solcher Video-Dateien man in der Datenbank haben möchte. Vidso-Sammler haben zu Hause schon mal ein paar hundert Terrabyte an Videos auf ihren USB-Laufwerken. Für eine gewöhnliche Firebird-Datenbank bräuchte man allerdings eine Festplatte, die das aufnehmen kann, und am besten kein USB-Laufwerk, denn die sind langsamer als Sata-Platten. Es soll aber auch die Möglichkeit geben, Firebird als Multi-File-DB zu verwenden, aber darüber weiß ich nichts Genaues ...

Der größte mir bekannte Ram-Speicher der Welt ist wohl der von IBM vor zwei Jahren entwickelte: Satte 120 Petabyte sollten damals durch den Verbund von 200.000 herkömmlichen Festplatten den größten Speicher der Welt bilden. Das sind über 125 Millionen Gigabyte

Die derzeit größten Sata-Platten scheinen nicht mehr als 4000 Gigabyte zu bieten. Ich hab jetzt über eine Stunde gesucht und konnte keine größere finden. Da kommt man als Filme-Sammler schnell an seine Grenzen, bedenkt man, daß hochwertige BluRay-Filme mindestens 4 Gigabyte groß sind, für größere Bildschirme wohl bis zu 20 GB. Das wären dann 200 Bluray-Filme pro 4 TB. Nicht die Welt ... Oder bei herkömmlichen 4,7-GB-Filmen (DVD) wären das imerhin mehr als 800 Filme.

Videos für kommerziellen Gebrauch sind ja meist nicht so groß: Rechnen wir mal 1 GB pro Video, würden auf die größte Sata-Platte um die 4000 Videos passen, das könnte man dann schon in einer Multiuser-DB unterbringen ...

Man kann ohne Videos in der DB aber dennoch einen Multiuser-Zugriff entwickeln. Ich würde hier eine 3-Schicht-Lösung anstreben: Client - Zwischenschicht - Datenbank. Requests werden dann an die Application gestellt, die ich laienhaft als Zwischenschicht bezeichne, und diese packt dann die angeforderten Daten aus Datenbank und Dateisystem zusammen und schickt sie an die Client-App.

[PhilmacFLy]

Mit dem Unterschied das die Videos die ich mach maximal 10s lang sind und damit ungefähr eine größe von ca 20-30 mb haben.

[IBExpert]

Bezgl. Videos in Datenbank: Es spicht nichts dagegen, zum Beispiel mit Techniken wie EXECUTE STATEMENT ... ON EXTERNAL für Videos, die ja nun mal per se relativ statisch sind, eine eigene Datenbank zu haben, die ich aber aus meiner Datenbank transparent abrufen kann.

Wir machen das mit dem Bereich Dokumentmanagement, wo einfach alle PDF und Bilddateien der Thumbnails monatlich in eine zweite teilweise sehr große Archivdatenbank verschoben werden, diese wird nach der Übertragung dann auf Readonly gesetzt und braucht auch nur ein mal pro Monat gesichert werden.

Während des Monats laufen dann die neue PDFs und Images in die Produktionsdatenbank hinein, die dann beim nächsten Monatswechsel wieder archiviert werden. Der Zugriff auf die Dokumente läuft dabei über eine Tabelle, in der die Volltextdaten enthalten sind, diese bleibt auch immer komplett in der Echtdatenbank. Der Zugriff auf die JPG oder PDF Daten erfolgt immer über den Umweg einer Prozedur und diese entscheidet intern, das das Objekt, das in der Produktsdatenbank gerade ein leeres Blobfeld hat, eben per execute statement on external die daten aus der anderen DB holt, die ggf sogar auf einem anderen Server liegen kann.

Die Übertragung in die zweite DB als auch der Zugriff läuft alles ab fb25 mit Bordmitteln.