Laden...

Dateien in Datenbank?

Erstellt von Sclot vor 13 Jahren Letzter Beitrag vor 13 Jahren 9.780 Views
S
Sclot Themenstarter:in
324 Beiträge seit 2007
vor 13 Jahren
Dateien in Datenbank?

verwendetes Datenbanksystem: <MySQL>

Für ein Internes Programm entwickeln wir hier eine Erweiterung um Dateianhänge zu ermöglichen.
Nun sind wir uns unsicher ob wir diese Dateianhänge auf dem Server direkt im Dateisystem speichern oder mit in der Datenbank.

Meine Meinung:
Wenn wir die ganzen Dateien in der DB speichern, bläht sich die DB unnötig auf.

Jetzt wär die Frage warum überhaupt Dateien in Datenbanken gespeichert werden.
Welche Vor- oder Nachteile hat das ganze?

Warum muss ich mir von Kollegen anhören: "Wir speichern die Dateien generell in die Datenbank, weil ALLE guten Software-anbieter mit SQL Server als DB das machen!" ?

Ich brauch mal bitte ein paar Kompetente Meinungen dazu.

Danke! 😃

3.511 Beiträge seit 2005
vor 13 Jahren

weil ALLE guten Software-anbieter mit SQL Server als DB das machen

Das liegt daran, das der SQL Server es einfach besser als mySql kann 😃

Aber zum Thema:
Dateien in der DB machen durchaus Sinn. Wenn z.B. die DB von Server zu Server wandert (z.B. Sicherung wiederherstellen). Wenn die Server in einem Cluster hängen. Wenn Server gespiegelt werden. In all diesen Szenarien, hat man eigentlich schon verloren, wenn nur der komplette Dateipfad in der DB gespeichert wird. Sichert man eine DB, vergisst aber die Dateien, hat man auch verloren. Mit einer DB hast du alles aufeinmal. Und ob ich nun eine DB mit 1GB und 10GB Dateien habe, oder eine DB mit 11GB Größe, spielt doch mal überhaupt keine Rolle. Der Speicherplatz ist so oder so verbraten. Das Argument "bläht sich die DB unnötig auf" ist also total hinfällig.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

was auch noch hinzu kommt ist dass beim Speichern von Dateien in der DB der komplette Zugriff auf die Dateien über die DB erfolgt. Somit vereinfacht sich der Zugriff auf die Dateien und die Sicherheitsverwaltung kann auch über die DB erfolgen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

T
415 Beiträge seit 2007
vor 13 Jahren

Ich halt mal gegen meine beiden Vorredner und sage, dass beim Einsatz von MySql die Performance bei großen Datenmengen sich deutlich verschlechtern kann. Die Abfragezeit steigt extrem zur Datenmenge die die Query erfasst.

Den Einwand von gfoidl verstehe ich nur teilweise. Durchaus richtig, dass so auch gleich die Sicherheitsverwaltung über die DB abgedeckt ist. Aber der Zugriff kann sich dadurch in die Länge ziehen. Nehmen wir an wir haben eine 300 MB große Photoshop Datei in der DB gespeichert. Der User will drauf zugreifen, so muss zuerst eine Kopie an den gewünschten Ort stattfinden. Das kann etwas dauern. Hab ich nun aber einen Pfad gespeichert (z.B. zu einem Netzlaufwerk wo die Datei liegt), so kann der Zugriff direkt erfolgen.

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

Aber der Zugriff kann sich dadurch in die Länge ziehen

Für das von dir geschildere Szenario schon. Anderes Beispiel wäre ein Video das in der Datenbank ist an den Client zu streamen. Hier ist die DB-Speicherung wieder im Vorteil (zumindest beim SQL Server da der FileStream direkt weiter geleitet wird, wie es bei mSQL ist weiß ich nicht).

Es kommt halt sehr darauf an für was man es braucht 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

F
10.010 Beiträge seit 2004
vor 13 Jahren

Warum MySql?

Das ist eines der "Überhyptesten" OpenSource Projekte überhaupt.
Kann vieles nicht, ist vergleichsweise langsam und im kommerziellen Umfeld viel zu teuer.

Wenn ihr schon nicht den MS Sql ( auch Express ) einsetzt, solltet ihr evtl mal ne echte OS DB wie PostGreSQL oder FireBird benutzen.

Dann seht ihr mal, wie langsam MySql übers Netzwerk ist.

Und zum Thema:
@t2t:
Wenn man die DB von Vornherein vernünftig designed und die richtigen Felder in einen Index Packt, wird selbst MySql mit sowas nicht sonderlich langsam.

@Sclot:
Neben DB2 hat auch MS mit der Sql 2008 Version extra FileStreams im Server eingeführt, und das auf grosse Nachfrage der Entwickler weil immer mehr Files gesichert werden müssen und sonst das von Khalid beschrieben Problem entsteht.

S
Sclot Themenstarter:in
324 Beiträge seit 2007
vor 13 Jahren

so.. bin wieder da...

Warum MySQL?
Weil der sehr viel ressourcensparender ist als MSSQL, die MySQL-Menschen zwar nerven, aber sehr nett sind... MySQL kann in der Comunity Edition (weil in meinem Fall für ein Internes Projekt) mehr RAM benutzen als der MSSQL Server Express...
Und letzendlich sitzt das Knowhow bei uns Intern mehr im MySQL bereich, statt im MSSQL bereich 😉

Aber.. hier gehts nicht um für oder gegen MySQL sondern für oder gegen Dateien in der DB speichern.

Sicherheit spielt keine rolle - ist wie gesagt ein internes Projekt wo quasi alle Mitarbeiter Vollzugriff drauf haben.
Die FileStream Möglichkeit vom MSSQL2008 ist mir bekannt, habe ich aber noch nicht wirklich produktiv ausprobiert - soweit ich weiss gibt es etwas vergleichbares in MySQL aber nicht.
Letztendlich laufen unsere SQL Server auf Virtualisierten Kisten.
Der Direkte Dateisystemzugriff wäre im Idealfall auf einer Freigabe direkt auf dem Storage.
Hierbei wäre dann auch gleich erwähnt das 11GB statt 1Gb in einer Virtuellen Maschine, die Täglich gesichert wird schon einen gewaltigen Unterschied machen 😉

Ja.. Im Prinzip bin ich noch nicht schlauer.. mhm...
Dateien in der DB würde für mich bedeuten dass ich den BLOB beim zugriff temporär in eine Datei schreiben müsste und diese dann lokal aufrufen müsste.
Dauert ohne frage eine gewisse zeit länger als ein direkter Dateizugriff.
Dateien wie Bilder, Fotos oder zip/rar Dateien in eine Datenbank zu legen, die man nicht durchsuchen kann, finde ich auch fragwürdig.

Da muss ich wohl noch eine Nacht drüber schlafen.

3.511 Beiträge seit 2005
vor 13 Jahren

Dateien wie Bilder, Fotos oder zip/rar Dateien in eine Datenbank zu legen, die man nicht durchsuchen kann, finde ich auch fragwürdig.

Wo wir wider beim MS SQL Server wären, der kann das ohne Probleme (die richtigen IFilter vorrausgesetzt). 😃

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

X
1.177 Beiträge seit 2006
vor 13 Jahren

huhu,

Weil der sehr viel ressourcensparender ist als MSSQL [..] mehr RAM benutzen als der MSSQL Server Express

Naja - was nun? "Benutzt mehr Ram" beisst sich mit "ressourcensparend" 😃
ich denke die Grundlast, die beide Systeme erzeugen, ist auf allen gängigen Systemen vernachlässigbar.

Dateien in der DB würde für mich bedeuten dass ich den BLOB beim zugriff temporär in eine Datei schreiben müsste und diese dann lokal aufrufen müsste.

Nein, must Du nicht. Kommt auf den Anwendungsfall an. Wenn man z.B. ein Bild in einer Gui darstellt, dann muss man es
a) von der Platte in einen Stream in ein Image-Object laden
b) von der DB in einen Stream in ein Image-Object laden

Bleibt sich also gleich.

Dauert ohne frage eine gewisse zeit länger als ein direkter Dateizugriff.

Vermutlich - wenn das Bild lokal liegt. Ansonsten gibt es noch Faktoren wie: den DB-Server, den File-Server, das Netzwerk...

Dateien wie Bilder, Fotos oder zip/rar Dateien in eine Datenbank zu legen, die man nicht durchsuchen kann, finde ich auch fragwürdig.

Ähh, wie durchsucht du denn aktuell Bilder? Wenn du die "Metainformationen" meinst, ala mp3-ID-Tag, die kann man auch in der DB ablegen. Bei Zip-Dateien geb ich Dir recht, der Windows-Explorer durchsucht die tatsächlich - dazu muss der die aber auch erstmal in den Speicher laden und teil-entpacken.

Meine Meinung:

Es kommt auf den Anwendungsfall an.

In einer Webanwendung würde man den Webserver unnötig ausbremsen, wenn man die Bilder immer aus der DB holt, da diese bei statischen Files sehr fix sind.
Normale Office-Dokumente würde ich weiterhin im File-System speichern. Die Benutzer kommen damit besser zurecht (können auch mal kopieren und löschen und so).
Bestimmte Kataloge - z.B. eine LP-Cover Sammlung - sind in einer DB schön aufgehoben; man kann zusätzliche Infos (Interpret, Lyrics und die mp3-Files) hinterlegen.

Noch einen Punkt zu "Deinem" Problem:

Virtual-Machines und Sicherung: Virtual Machines sind so zu sichern wie "echte Maschinen" - und bei denen kommt doch bitte keiner auf die Idee, jede Nacht ein Image der Platte zu machen, oder?
Fals die Performance der VM nicht ausreicht, ist imho die DB am wenigsten schuld - das Design einer DB sollte nicht davon abhängen, auf welcher Ziel-Hardware sie läuft (und ob die Performance reicht). Wenn du dein Projekt um ein halbes jahr verschiebst/überziehst, dann kann sich die "Hardware-Seite" grundlegend geändert haben.
Man sollte ja auch nicht immer alles und jeden virtualisieren. Auch im "internen" umfeld machen sich schnelle Server bei der Produktivität der Mitarbeiter bemerkbar.

So, ob du jetzt Deine Dateien in der DB speichern sollst oder nicht, kann ich Dir nicht raten, denn ich hab nichtmal ne Idee was für Dateien und was für ein Einsatzzweck.

😃

Xynratron

Herr, schmeiss Hirn vom Himmel - Autsch!

Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.

175 Beiträge seit 2010
vor 13 Jahren

Hi,

wie Vorposter bereits richtig angemerkt haben, hat die Ablage der Daten in der DB gewisse Vorteile. Da wäre die direkte Bezug zu den Meta-Daten, Vorteile bei einer Replikation und beim Clustern.....

Aaaaaaber: Da Du das alles offensichtlich nicht brauchst, würde ich pers. zu einer Ablage im Dateisystem raten.

Grund #1 ist, dass die Datenbankfiles vom InnoDB nur wachsen können, aber niemals "schrumpfen" (ich nehme an Du/Ihr verwendet InnoDB als Storage-Engine vom MySQL). Das finde ich pers. sehr unpraktisch, denn die DB-Dateien für das Backup werden immer größer und müssen ja auch täglich neu gesichert werden - sprich, dein benötigter Backup-Space wächst und wächst und wächst und .....

Grund #2 ist eben das Backup der DB: Wenn Du/Ihr ein "Turnschuh-Backup" der MySQL-DB macht (sprich mit "mysqldump"), dann ist es sehr vorteilhaft, wenn dieser Dump nicht diverse GB umfasst wegen der ganzen BLOBs. Auch ein Restore würde dann wesentlich schneller gehen. Die Dateien auf dem Server / SAN selbst werden (so unterstelle ich mal) eh vernünftig von einer Backup-Software gesichert.

Grund #3: Sofern die Dateien auf einem zentralen Storage liegen (z. B. einem SAN), dann kannst Du trotzdem die DB replizieren oder clustern, ohne dass Du Einbussen hast, weil die Daten/Dateien eben nicht in der DB als BLOBs gespeichert sind.

Grund #4: Wenn die Dateien auch mal gross werden können, dann möchte ich das DBMS eigentlich nicht mit dem Management dieser Daten belasten (ok, das ist jetzt sehr subjektiv). Aber wenn die Dateien auf einem anderen Server liegen als das MySQL (z. B. auf einem SAN), dann sollte das MySQL sich auch deutlich flotter anfühlen - denn es muss ja nicht "immens grosse Dateien" verschicken sondern beschäftigt sich "nur" mit den Queries auf die DB.

Aber auch ich muss mich den Vorpostern anschliessen: Ohne genau zu wissen was es für Dateien sind und ohne ein Mengengerüst, ist eigentlich eine handfeste Empfehlung nicht möglich....

Bye,
Michael

Debuggers don't remove Bugs, they only show them in Slow-Motion.

F
10.010 Beiträge seit 2004
vor 13 Jahren

@sclot:

Warum MySQL?
Weil der sehr viel ressourcensparender ist als MSSQL

Behaupten die MySql Leute immer, auch das MySql schnell wäre, ist aber nicht so.

Natürlich könnt ihr auch einen dedizierten Speicherort vorhalten, aber dann muss der auch täglich mit der DB gesichert werden.
Es ist also vollkommen egal ob ihr die VM mit MySql oder die VM mit den Daten sichert.

Aber warum meint ihr so ein Dokumenten Management System selber erstellen zu müssen?

S
Sclot Themenstarter:in
324 Beiträge seit 2007
vor 13 Jahren

Im Prinzip ist das nur die Einbindung von Dateianhängen für unser Internes Ticket-System.

Warum wir sowas immer selbst bauen?
Weil wir ein Chef haben,d er meint das wir Programmieren können und alles selbst bauen können, statt es teuer extern zu kaufen 😉
Ich wäre euch echt Dankbar, wenn wir diesen Punkt jetzt bitte nicht weiter diskutieren würden 😃

Und noch mal zu dem Thema MySQL vs. MSSQL oder PostgreSQL oder sonst was: WIR haben hier einfach die meiste Erfahrung mit MySQL, darum diese DB 😃

Zu dem Tabellenformat: da wir in dem Fall keine Transaktionen brauchen, benutzen wir normale MyISAM Tabellen. InnoDB ist hier nicht nötig.

Und zur Frage was wir da letztendlich für Dateien rein tun würden:

  • EML Dateien (Exportierte E-Mails)
  • TIFF Dateien (Faxe)
  • MP3 (Voice Nachrichten vom Anrufbeantworter)
  • sonstige Dokumente die anfallen: pdf, jpg, xls, doc, txt...

Es geht hierbei wirklich nur um eine stumpfe Dateiablage.
Ich möchte gar keine MetaInformationen erfassen und in diesen suchen können.
Ich möchte einfach nur wissen was für und gegen der Speicherung von solchen Dateien in einer DB spricht.

Das wurde ja jetzt schon recht gut beschrieben.

W
955 Beiträge seit 2010
vor 13 Jahren

Wenn ich mich noch an meine Zeit als Oracle-DBA erinnere war der Hauptdiskussionspunkt dann immer ob die Dateien transaktionsgeschützt sein müssen, was ja bei Dir nicht der Fall ist.

3.511 Beiträge seit 2005
vor 13 Jahren

Eins fällt mir noch ein:
Was passiert eigentlich, wenn ich auf der Freigabe einfach eine Datei lösche? Der Dateiverweis in der Datenbank bleibt ja bestehen...

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

175 Beiträge seit 2010
vor 13 Jahren

Eins fällt mir noch ein:
Was passiert eigentlich, wenn ich auf der Freigabe einfach eine Datei lösche? Der Dateiverweis in der Datenbank bleibt ja bestehen...

Das müsste man dann organisatorisch klären - z. B. mit passenden ACL's auf Dateisystemebene. Oder beispielsweise den lesenden Zugriff nur per HTTP zu erlauben (sprich, die Dateiablage vor dem Benutzer "verbergen" und ihm so die Möglichkeit die Dateien zu löschen "verbergen")...

Ich denke, der Phantasie sind hier keine Grenzen gesetzt 😉

Bye,
Michael

Debuggers don't remove Bugs, they only show them in Slow-Motion.

175 Beiträge seit 2010
vor 13 Jahren

Zu dem Tabellenformat: da wir in dem Fall keine Transaktionen brauchen, benutzen wir normale MyISAM Tabellen. InnoDB ist hier nicht nötig.

Ich will hier ja keine Diskussion vom Zaun brechen - aber diese Einstellung würde ich mir gründlichst überlegen....

Ich kenne zwar die Applikation nicht, aber ein Ticket-System ohne die Sicherheit von Transaktionen.... ääääähhhh... Aber nungt, Ihr wisst sicherlich was Ihr tut - ihr könnt ja programmieren (sagt der Chef ja auch) 😉))))

Aber der eigentliche Grund meines Postings: Ich meine mich zu erinnern, dass MyISAM so langsam dem Tod entgegen rennt... War da nicht letztens 'ne News, dass jetzt die Datenbank "mysql" nicht mehr auf myISAM angewiesen ist und diese Storage Engine jetzt früher oder später aus MySQL entfernt werden wird?!?!? Ich meine da war was...

Von daher würde ich mir ganz gut überlegen, ob ich heute noch auf myISAM setze. Ich würde es nicht tun....

Bye,
Michael

Debuggers don't remove Bugs, they only show them in Slow-Motion.

S
Sclot Themenstarter:in
324 Beiträge seit 2007
vor 13 Jahren

Selbst wenn, ein Umstieg auf InnoDB (dump raus, dump rein) sollte jetz nicht das problem sein 😃
Und ein Umstieg auf MariaDB sollte notfalls auch kein problem sein 😉

Nein, Ich denke nicht das MyISAM eingestellt wird.
Die News wäre trotzdem sehr interessant, falls du den Link noch mal wieder findest 😃
Ich denke mich daran erinnern zu können das z.b. InnoDB nicht so gut mit Partitionierten Tabellen umgehen kann. Es gibt in jeder Speicher-Engine Vor- und Vachteile 😃
Trotzdem - der Umstieg auf ein anderes Tabellen-Format ist genauso problemlos möglich wie der Umstieg auf einen anderen DB Server. Das einzige was bei letzterem fehlt ist das Knowhow es zu benutzen.

Sicherheitsprobleme gibt es bei uns nicht.
Wir sitzen alle im selben Boot und haben schon das gewisse Grundvertrauen in die Leute... das ist bei einer 15-Mann Firma noch recht übersichtlich.
Das löschend er Datei ist aber durchaus ein Problem.
Wenn der Virenscanner eine Datei löscht, dann gibt es auch einen toten Verweis in der DB.

Mhm... Vielleicht sollte ich mich doch mal mit den Gedanken anfreunden Dateien mit IN die DB zu packen.

6.911 Beiträge seit 2009
vor 13 Jahren

Hallo,

Das löschend er Datei ist aber durchaus ein Problem.

Auch das Umbennen 😉
Triviales Beispiel: Ein Dateiname enthält einen (Rechtschreib-) Fehler und ein eifriger Mitarbeiter korrigiert das -> die DB wird aber nicht (automatisch) aktualisiert.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

I
1.739 Beiträge seit 2005
vor 13 Jahren

Zitat von: t2t
Ich halt mal gegen meine beiden Vorredner und sage, dass beim Einsatz von MySql die Performance bei großen Datenmengen sich deutlich verschlechtern kann. Die Abfragezeit steigt extrem zur Datenmenge die die Query erfasst.

Ein Grund mehr um BLOBS in eigene Tabellen auszulagern...
Also kein Grund der gegen Speicherung in einer DB spricht. Die Files werden bei Bedarf geladen.
Ein Grund der gegen DB-Haltung der Dateien(damit für Links) sprechen könnte wäre ein entsprechender Workflow(am besten im Verbund mit geregelten administrativen Rechten aufs Dateisystem und sonstiges). Nicht jeder der eine Datei aktualisieren kann muss zwangsläufig Zugriff auf die DB oder ihre aufgesetzte Anwendung haben.
Nebenbei ergibt sich bei Haltung der Binärdaten in der DB oft ein sinnloser Speicherverbrauch durch doppelte Datenhaltung.

J
1.114 Beiträge seit 2007
vor 13 Jahren

Auch das Umbennen 😉
Triviales Beispiel: Ein Dateiname enthält einen (Rechtschreib-) Fehler und ein eifriger Mitarbeiter korrigiert das -> die DB wird aber nicht (automatisch) aktualisiert.

Eigentliche alle Operationen am offenen Herzen sind kritisch.
Wenn man wirklich viele solcher Dateien im Filesystem ablegt, tut man gut daran, auch eine Ordnerstruktur einzuführen. Ich hatte mal in der Vergangenheit meine Files einfach in ein Serververzeichnis gepackt. Damals ging es um tägliche Scans. Nach 6 Monaten lagen 50.000 Dateien im Verzeichnis rum. Das macht den Zugriff sicherlich nicht schneller. Also habe ich angefangen, ein Verzeichnis mit dem Jahr anzulegen und 12 Unterverzeichnisse für den Monat. Damit blieb das Ganze überschaubar und auch Backups gestalteten sich wesentlich schlanker... Aber wegen dieser neuen Verzeichnisstruktur kam es dann tatsächlich einmal vor, dass sich ein User kurz verklickt hat und einfach mal so mittels Drag and Drop ein Verzeichnis sonstwo verschoben hat.

Deshalb wiederhol ich mich gern: Operationen am offenen Herzen sind immer kritisch, und die sollte man vermeiden.

Und da ich Verfechter von 3-Tier bin (gfoidl sicher auch 😃 ), sollten Zugriffe von Clients nic direkt auf die DB erfolgen oder direkt Zugriff auf das Filesystem haben. Sicherheit kann man dann vergessen und es passieren so Dinge wie oben geschildert. Ausserdem kann ich nicht einfach mal so einen bestimmten Datensatz für eine Benutzer sperren. Auf DB Ebene geht das veilleicht noch, auf Fileebene wirds schon schwieriger.

Wenn also eine 3-Tier Architektur vorliegt, spielt es imho keine Rolle, wo die Blobdaten abgelegt sind, in der DB oder im FS. Erfolgt der Zugriff direkt vom Client auf die DB, würde ich vermutlich alles in die DB packen.

Wieviel Daten fallen denn so im Monat an, und wie gross sind die einzelnen Files durchschnittlich?

H
222 Beiträge seit 2010
vor 13 Jahren

Hallo Leute,

ich stehe gerade vor dem gleichen Problem, allerdings mit MSSQL 😃
Bei meinen Recherchen bin ich auf folgendes gestoßen:

To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem

sieht auf den ersten Blick äusserst professionell aus. Werd mir dass mal durchlesen
und dann eine Entscheidung treffen...

Die Welt hat genug für jedermanns Bedürfnisse, aber nicht für jedermanns Gier.

1.820 Beiträge seit 2005
vor 13 Jahren

Hallo!

Hoffe, ich hab einen ähnlichen Hinweis nicht überlesen, und möchte daher mal SharePoint mit ins Spiel bringen. Dort werden alle Dateien ebenfalls in die DB gepackt. Der Vorteil hier ist die Möglichkeit der zentralen Verwaltung UND Bearbeitung (die Dateien können direkt in Office bearbeitet und wieder gespeichert werden), d.h. verschiedene lokale Versionen gehören somit prinzipiell der Vergangenheit an. Zudem hat man hier auch den Vorteil der Versionsverwaltung, kann also ggf. auch mal eine Vorversion anschauen.
Die genannten Asdpekte sind selbstverständlich auch über File-Systeme machbar, aber ein Benutzer nimmt in der Regel den geringsten Widerstand (z.B. Serverversion einfach überschreiben anstatt unter neuem Namen abzuspeichern), und dieser wird mit SharePoint verringert.
Und ich vermute mal, die Neuerungen im MS SQL-Server bzgl. FileStreams sind auch motiviert durch SharePoint.

Nobody is perfect. I'm sad, i'm not nobody 🙁

F
10.010 Beiträge seit 2004
vor 13 Jahren

Wobei das ja für den Sql Server 2005 gilt.
Ab dem 2008 wurde ja aus dieser Problematik der FILESTREAM eingeführt, so muss man nicht mehr entscheiden in welches "File" die Daten kommen, bzw ab wann man Blob oder File nimmt.

S
5 Beiträge seit 2010
vor 13 Jahren

Hallo,

Ich rate dir auch generell davon ab Dateien in die Datenbank zu speichern.

Ich würde eine Kombination aus Dateisystem und Datenbank verwenden. In der Datenbank die Schlüssel und Dateinamen und sonstige Dateiinfos speichern und die Daten selber im Dateisystem ablagern.

Damit du keine Konflikte mir Dateinamen etc bekommst am besten den Internen db Schlüssel als Dateinamen verwenden.

Falls Verzeichnisstrukturen innerhalb der Anwendung gewünscht sind würde ich diese wieder über die Datenbank verwalten. Das wird sonst unnötig kompliziert.
Generell würde ich aber wenn man mit sehr vielen Dateien rechnen kann nicht alle Dateien im einem Verzeichnis kopieren. Z.B. max 1000 Dateien in einem Verzeichnis anlegen und wenn diese erreicht sind ein neues Verzeichnis anlegen. Dieses einfach auch nur mit einer fortlaufenden Nummer.

Als Endpunkt und schliesslich um auf die Dateien zuzugreifen bietet sich ein Wcf-Service an. Hier sollten dann funktionen drin liegen um sich den Stream zu holen oder hochzuladen. Falls Dateien auch bearbeitet werden müssen muss noch an einem locking Mechanismus gedacht werden. Dies läßt sich aber auch recht umkompliziert umsetzen. Dateien dürfen auf nur über den Service gelöscht werden. Der Service muss selber auch darauf achten das das Dateisystem mit der Datenbank synchron bleibt. Hier solltest du aber bei MySql das InnoDb System verwenden. Das Isam unterstützt meinem Wissen her keine Transaktionen und diese sind hier total wichtig um sicher zu gehen das die Datenbank mit dem Dateisystem synchron bleibt.

Ich habe grob in der Art einen FileService entwickelt und es funktioniert sehr gut. Das Streaming per Wcf geht geht schnell und die Datenbank bleibt schön kompakt und schlank.

In meinem Service speichere ich auch noch Blobs in der Datenbank ab. Hier aber nur wenn es sich bei der jeweiligen Datei um ein Bild handelt. Wenn das der Fall ist wird ein Thumbnail erstellt und abgespeichert.

Hoffe das ich dir ein paar Tips geben konnte

Sorry wegen den Rechschreibfehlern .. viel zu tun heute .. aber irgendwie wollte ich unbedingt zu dem Thema was posten 😉

lg Sascha

3.511 Beiträge seit 2005
vor 13 Jahren

Ich rate dir auch generell davon ab Dateien in die Datenbank zu speichern.

Was generell eine falsche Aussage ist 😃
Es kommt auf das System und die Anforderungen an.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

H
116 Beiträge seit 2008
vor 13 Jahren

Hi,

grundsätzlich würde ich im Regelfall Dateien immer in der Datenbank speichern, egal, welches DBMS zum Einsatz kommt. Vorausgesetzt natürlich, die Datei ist integraler Bestandteil des Datensatzes (also ein Foto zu einer Adresse oder ein Pdf zu einer Fakturierung). Letztlich ist es Aufgabe des DBMS die zu verwaltenden Daten effizient zu speichern. Ist das DBMS damit überfordert, sollte es ausgetauscht werden, denn Workarounds (und als solchen müsste man Verweise auf eine Datei im Verzeichnissystem verstehen) sind fehlerträchtig und schaffen Inkonsistenzen (Stichwort ACID).

Ist jedoch die Datei kein integraler Bestandteil eines Datensatzes, so kann man auch einen Verweis setzen. Mit URL's tun wir das schließlich auch, ohne zu wissen, ob die URL in Zukunft überhaupt noch erreichbar sein wird. Umgekehrt: Ist der Inhalt der URL von essentieller Bedeutung (etwa eine bestimmte Version eines Wikifehlia-Artikels als Quellenangabe), so würde man (zumindest ich) die entsprechende Version der URL komplett dem Datensatz hinzufügen, so dass dieser auch bei einer Nichterreichbarkeit des entsprechenden Servers verfügbar wäre.

Die Betrachtung ist jetzt zwar weniger technisch, aber ich habe es so gelernt: Schaffe ein Anforderungsprofil und wähle dann die passenden Werkzeuge.

Hinrich