Wenn Microsoft MOSS so erstellt, dass alle Daten in die SQL Server-Datenbank geschrieben werden, warum schlagen alle Best Practices für die Entwicklung vor, Dateien usw. außerhalb der Datenbank, d.Sharepoint MOSS angepasste v uncustomized
Alles Gute
Dies ist ein philosophischer Artikel. Transaktionsintegrität ist ein Vorteil der Speicherung der Dateien in der Datenbank. Damit einher gehen Nachteile wie das Aufblähen von Transaktionsprotokollen.
wäre ich nicht überrascht sein, wenn in zukünftigen Versionen von Sharepoint, MS Sie eine Option gab die Dateien zu speichern ‚außerhalb der Datenbank‘ durch das Filestream-Funktion von SQL 2008 verwenden
Aufgrund der Performance-Probleme: sparen ein Hin- und Rückweg in die Datenbank, nur um das Seitenlayout zu holen, auf Kosten der Leistung.
Auf der anderen Seite reduziert die Verwendung von Dateien auf dem lokalen Dateisystem für die Leistung Anpassungsoptionen.
Sie müssen die Dateien in der Datenbank behalten, wenn Sie möchten, dass Benutzer der Website diese Dateien bearbeiten. SharePoint ist so konzipiert, dass die meisten dieser Dateien bearbeitbar sind, sodass sie in der Datenbank gespeichert werden können.
Wenn Sie als Anwendungsarchitekt wissen, dass einige häufig verwendete Dateien (Seitenlayouts, Masterpages usw.) nur mit einer Lösungsversion bearbeitet werden, können Sie die Seiten im Dateisystem speichern.
Das Speichern auf dem Dateisystem hat eine kleine Verbesserung beim Einlesen der Zugriffsleistung, da ein Datenbank-Umlauf nicht erforderlich ist. Die Masterpage wird zum Beispiel für jede Seite der Website benötigt, so dass die Speicherung auf dem Dateisystem die Leistung bei hoher Benutzeranforderung verbessert.
Die Tatsache, dass SQL 2008 die Möglichkeit bietet, Dateien "außerhalb" der Datenbank zu verwalten, zeigt, dass diese Funktion nicht nur für SharePoint wünschenswert ist.
Wenn Sie SharePoint-Seiten uncustomized beibehalten, kann eine Instanz der Seite bei der ersten Ausführung kompiliert werden, dann im Speicher behalten und für alle Seiten derselben Art wiederverwendet werden. Der Grund, warum angepasste Seiten dieses Verhalten nicht teilen, liegt darin, dass sie eindeutig sind. Sobald eine ApplicationDomain eine DLL lädt, kann sie nicht mehr entladen werden. Daher werden angepasste Seiten bei jeder Anfrage analysiert.
Ich würde sagen, dass alle Best Practices nicht sagen, dass Sie das Dateisystem zum Speichern von Dateien verwenden sollten. Es wird immer von der Situation abhängen. Das Speichern von Dateien im Dateisystem ist in Ordnung, wenn Sie einen einzelnen Server haben, aber dann müssen Sie die Replikation verwalten, wenn sich die Dateien auf mehreren Servern befinden müssen. Das Sichern einer Datenbank ist in der Regel einfacher als eine Datenbank und Dateien. All diese Situationen können gemanagt werden, aber Sie müssen flexibel sein.
Woher haben Sie diese "Best Practices"?
In meiner Erfahrung mit MS und MOSS sollte ich sagen, dass noch nie von solchen Best Practices und abgesehen von einem ganz besonderen Fall gehört habe ... Ich würde sagen, dass dies keine gute Praxis ist.
Ihre deploy ist dieser Weg nicht einfach ... Admin-Benutzer wissen, wo zu finden, welche Datei zu ändern, Sicherungen wie die Hölle sind, etc
Aber, wie ich sagen ... in einem bestimmten sein kann Fall Es könnte nützlich sein.
Ich spreche über Entwicklung hier, d. H. Funktionen, Lösungen, Masterseiten, Layouts, Webparts usw. Die meisten technischen Bücher/Artikel von MVP vorschlagen, die Dateien auf dem Dateisystem und nicht in der Datenbank zu halten .... Ich denke! ;) – 78lro
Die SharePoint hat eine Technologie namens ghosing, die Pager im Dateisystem Caching ist.
Ich habe nicht von solchen "Best Practices" gehört ... 100% stimmen mit Ihnen überein. Ich versuche immer alles in die Inhaltsdatenbank zu legen. – Romias