Hallo liebe Kollegen,

ich komme aus der VB6-Welt und hatte hier eine auf Access bassierende kaufmännische Anwendung.

Sämtliche Dateien wie

• Bilder (jpg)
  
• Worddokumente
  
• Exceldateien
  
• usw.

habe ich direkt im Filesystem gespeichert, der Speicherort war in der Datenbank (z.B: strDatenpfad + "\Testbild.jpg")
In der Praxis war dieses sehr umständlich und fehleranfällig, vor allem im Netzwerkbetrieb.

In meiner neuen WPF-Anwendung würde ich gerne sämtliche Dokumente direkt in der Datenbank speichern.
Somit erspare ich mir einen seperaten Einstellungsdialog, ein gemapptes Laufwerk (war für List&Label notwendig) und vieles mehr.

Die neue Anwendung kommt wie folgt zum Einsatz:

• Einplatzsysteme
  
• Mehrplatzsysteme
  
• Mehrplatzsysteme an unterschiedlichen Standorten

Gerade für das dritte Einsatzgebiet ist es natürlich ideal, wirklich alles in die Datenbank zu speichern. Man installiert einen Client,gibt den SPeicherort der Datenbank an und hat sofort sämtliche Daten inkl. Dokumenten.

Ich habe allerdings folgende Bedenken:
Jeder Kundendatensatz hat mindestens 1 Bild (200kb), ca. 20 Worddokumente usw.

• Mir macht hier die Performance sorgen, ist die Anwendung letztendlich schnell genug?
  
• Gerade im Netzwerkbetrieb und mit mehreren Standorten?
  
• Oder ist es möglich, nur Text zu laden und die Dokumente bei Bedarf?
  
• Macht es Sinn, 1 Datenbank für die Daten und 1 für Dokumente zu halten (bspw. wenn ich die Datenbank zu mir hole per Teamviewer)?

Mir geht es nur um den grundlegenden konzeptionellen Ansatz, Feedback wäre wirklich klasse.

Servus,

ich würde dir ganz klar dazu raten weiterhin mit einem Verzeichnis zu arbeiten.

Du müsstest die Dateien sonst Base64 kodiert in einem BLOB speichern. Base64 hat so die 2-3 fache Größe der Datei. Das wird schnell groß.

MrTrebron schrieb:

Base64 kodiert in einem BLOB

Warum?
BLOB ist binär und benötigt keine Text-Codierung, nur CLOB setzt das voraus.


Für mich stellst sich eher die Frage, ob die Dateien auch ausserhalb der Anwendung benötigt oder verändert werden müssen.
Wenn du sie in der DB speicherst, bindest du sie hart an die Anwendung und kannst sie nur damit ein- und auschecken.
Wenn du diese enge Bindung akzeptieren oder sogar forcieren willst, spricht nichts gegen eine DB-interne Lagerung.

Gerade bei mehreren Standorten (womöglich noch in mehreren Ländern?) halte ich es für sinnvoll, lokale Templates zu erlauben und nur deren Inhalt aus der Datenbank zu füllen.

Ich frage mich aber, welche Datenbank du verwenden willst, wenn die gleichzeitig Standalone-Systeme als auch Mehrplatzsysteme bedienen soll.
Standalone würde heissen, dass die DB dringend auf dem Client gespeichert sein muss.
Und im Netzwerk sollte alles von einer zentralen DB aus gehen, damit sich Änderungen auch auf die anderen Systeme auswirken.

Welches DB-System willst du denn verwenden?

zB mit SqlServer kann man alles in dieselbe DB packen.
Gedanken sollte man sich aber zum Datenmodell machen, etwa dass man Blobs in besondere Tabellen auslagert, auf die verwiesen wird.
Dann kann man die Standard-Datensätze weiterhin in großen Portionen ratzfatz abrufen, und nachladen einzelner Bilder etc. dann halt in gesonderten Abfragen.
Um den Traffic niedrig zu halten, und auch den Speicher-Verbrauch im Client.

Ich bin mal mit einem zunächst paradox anmutendem Datenmodll gut gefahren:
Nicht der Artikel-Datensatz verwies auf die Bild-Datei, sondern der BildDatei-Datensatz verwies auf den Artikel.
Also die Relation (quasi falschrum):
Artikel -> Bild
Und programmgesteuert sorgte ich dafür, dass jedem Artikel nur ein Bild zugeordnet war.
So konnte ich mit Leichtigkeit viele (in meinem Fall: alle) Artikel laden, und wenn einer angewählt wurde lud und präsentierte ich "alle" dessen Bilder nach (es war nur eines - oder keines)

Aber wie gesagt: Bestimmte Provider - wie zB Access - kriegen so Riesen-Datenbestände nicht gebacken, für andere - SqlServer, MySql, Oracle,... - ist das kein Thema.

@ErfinderDesRadesnull
vielen lieben Dank für Deine Antwort, so habe ich es geplant. Es reicht also, wenn ich sämtliche Dokumente in eine besondere Tabelle (also nicht in einer separaten Datenbank) auslagere und darauf verweise. Die Tabelle [Kunden] verweist dann also auf die Tabelle [Dokumente], hier lade ich bei Bedarf die Dokumente.
Als Datenbank verwende ich den SQL-Server, nie wieder Access.

@petaod
Ich möchte den SQL-Server verwenden.

Ja, ich benötige die Dateien auch außerhalb der Anwendung, das ist gerade der Sinn.
Der Anwender klickt bspw. das Dokument an, es öffnet sich in Word (oder TextControl). Es wird dann bearbeitet und dann wieder in die Datenbank zurückgeschrieben.

@MrTrebron
Vielen Dank, aber das hat zu viele Nachteile. Mache es seit 15 Jahren so und möchte hier gerade weg.
Wenn es keine Probleme bei der Performance gibt, spricht ja auch nichts dagegen. Vor allem kann ich im Mehrbenutzerbetrieb klarer steuern, Meldungen über gesperrte Dateien kommen dann von meiner Anwendung und nicht von Word.

HartBach schrieb:

Die Tabelle [Kunden] verweist dann also auf die Tabelle [Dokumente], hier lade ich bei Bedarf die Dokumente.

Wie gesagt: Was ich skizziert habe, verweist grad andersrum.
Und wenn deine Kunden mehrere Dokumente haben, dann geht das nur auf meine Weise, und deine Art zu verweisen muss failen.

Es gibt übrigens glaub sog "dokumenten-orientierte" Datenbanken - die sind von vornherein auf sowas ausgelegt, und ticken auch anders als Sql.
Hab ich keine Ahnung von, aber ehe du was anfängst, solltest du das gut recherchieren - ob das nicht exorbitant besser wäre - oft denke ich Sql selbst ist eiglich ziemlich veraltet und vermurkst.

Dazu habe ich eine Frage...
Ich löse so etwas über eine m:n-Tabelle

wo z.B. ein Produkt mehrere Dokumente zum Nachladen haben kann.
Ist das jetzt der falsche Weg...

kann man pauschal nicht sagen, kommt immer auf die Realität an, die modelliert wird.
Bei meine Artikel mit Bildern gehörten die Bilder genau einem Artikel, und wenn der Artikel nicht mehr da war, dann sollte auch das Bild weg.

Aber ein Dokument könnte sich ja auch auf mehrere Produkte beziehen, dann wäre m:n korrekt.

Danke,
ja - mehrere Produkte können auch ein und das selbe Dokument haben...

HartBach schrieb:

Ja, ich benötige die Dateien auch außerhalb der Anwendung, das ist gerade der Sinn.

Dann haben sie in der Anwendung bzw. deren DB nichts verloren.
Also bleib bei Links.

Achte aber darauf, dass die Verzeichnisstruktur sauber ist und sichergestellt, dass die Dateien an derselben Stelle bleiben.
Wenn das nicht der Fall ist, bekommst du Leichen in der Datenbank und du kannst dich nicht mehr darauf verlassen.
Falls eine saubere Ordnung nicht gewährleistet werden kann, speichere weder die Links noch die Dateien in der DB, sondern lass die Anwendung im Bedarfsfall die Dateien intelligent suchen.

HartBach schrieb:

Mir geht es nur um den grundlegenden konzeptionellen Ansatz, Feedback wäre wirklich klasse.

Da Du den MS-SQL Server benutzen möchtest/darfst/kannst (vielleicht sogar 2012?) - hier ein lesenswerter Artikel: LINK