Zur Zeit haben wir Tausende von Microsoft Word-Dateien, Excel-Dateien, PDFs, Bilder usw. in Ordnern / Unterordnern gespeichert. Diese werden regelmäßig von einer Anwendung generiert und können innerhalb dieser Anwendung jederzeit abgerufen werden. Während wir uns um ein Upgrade bemühen, werden jetzt alle diese Dokumente in SQL Server 2005 gespeichert. Gründe hierfür sind, dass Sie die Dokumente komprimieren können, indem Sie zusätzliche Felder hinzufügen, um weitere Informationen zu diesen Dokumenten zu speichern, und gegebenenfalls Indizes hinzufügen.
Ich nehme an, was ich möchte, ist die Vor- und Nachteile der Verwendung von SQL Server als Dokument-Repository, anstatt sie auf dem Dateiserver zu halten, sowie jede Erfahrung, die Sie dabei haben könnten.
Wir würden C # und Windows Workflow für diese Aufgabe verwenden.
Danke für Ihre Kommentare.
Bearbeiten
Wie groß sind die Dateien?
zwischen 100k = 200k Größe (durchschnittlich 70KB)
Wie viele werden sein?
Im Moment sind es etwa 3,1 Millionen Dateien (von Word / Excel und PDFs), die um 2600 pro Tag wachsen können. (Das Wachstum wird auch im Laufe der Zeit zunehmen)
Wie viele Lesevorgänge?
Dieser ist schwer zu quantifizieren, da unser altes System / Anwendung es schwierig macht, dies auszuarbeiten.
Auch ein weiterer nützlicher Link, der auf einen ähnlichen Beitrag hingewiesen wurde, behandelt das Für und Wider beider Methoden.
Dateien Gespeichert in DB vs FileSystem - Vor- und Nachteile
Ich hätte beides.
Ich würde die Dateien mit einem eindeutigen Namen umbenennen, damit einfacher zu verwalten, und ich würde alle Metadaten in der Datenbank (Dateiname, Inhaltstyp, Speicherort im Dateisystem, Größe, Beschreibung, usw.), also Auf die Dateien wird (indirekt) über die Datenbank zugegriffen.
Vorteile:
Sie können auch auf einem Laufwerk komprimieren. Sie können RAID für Backup und Geschwindigkeit haben.
Faustregel für Doc-Größe ist:
%Vor%EDIT: Diese Faustregel gilt auch für FILESTREAM-Speicher in SQL Server 2008
Wenn Sie den vollständigen Upgrade auf SQL Server 2008 durchführen, können Sie die neue FILESTREAM-Funktion verwenden, mit der das Dokument als Spalte in einer Tabelle angezeigt wird und dennoch als Datei in einer Freigabe gespeichert werden kann direkt von einem Programm (wie Word) zugegriffen werden.
Von welchen Dokumenten sprechen wir?
Das Speichern von Dokumenten in Ihrem SQL-Server ist möglicherweise nützlich, weil Sie die Dokumente mit anderen Tabellen verknüpfen und Techniken wie Volltextindizierung verwenden und z. B. unscharfe Suchen durchführen können.
Ein Nachteil ist, dass es etwas schwieriger ist, ein Backup der Dokumente zu erstellen. Und Komprimierung ist auch mit NTFS-Komprimierung oder anderen Techniken möglich.
Sind diese Dokumente textbasiert und planen Sie, die Volltextsuche von SQL Server zu verwenden, um diese Dokumente zu durchsuchen? Wenn nicht, sehe ich keinen Vorteil beim Speichern dieser Dokumente in der Datenbank. Natürlich können Sie die Metadaten zu den Dokumenten einschließlich der Pfadinformationen immer in der Datenbank speichern.
Ein großer Vorteil von streaming docs in der DB ist, dass es viel einfacher ist, den Sicherheitszugriff auf sie zu steuern, da Sie dies alles über die Zugriffskontrolle in Ihrer App tun können. Um sie auf einem Dateiserver zu speichern, müssen Zugriffsprivilegien auf Datei- und Ordnerebene behandelt werden, um direkten Zugriff zu verhindern. Auch haben sie in einem DB für einen einzigen Punkt der Sicherung, so können Sie leichter eine vollständige Kopie erstellen und / oder bewegen Sie es bei Bedarf.
Anstatt ein benutzerdefiniertes DMS (Dokumenten-Management-System) zu schreiben, sollten Sie in Betracht ziehen, einen zu kaufen oder WSS / SharePoint zu verwenden, da dies alle alltäglichen Details (Speicherung, Indizierung, Metadaten) verarbeitet und Sie Ihre benutzerdefinierten Funktionen erstellen können oben.
Tags und Links sql-server c# sql-server-2005 workflow-foundation