Gibt es gute Gründe, um Daten zu halten intern als XML?

StackOverflow https://stackoverflow.com/questions/1008564

Frage

In den Jahren, die ich an meinem Ort der Beschäftigung waren, habe ich einen deutlichen Trend zu etwas bemerkt, dass ich ein Anti-Muster betrachten: Pflege interne Daten als große Ketten von XML. Ich habe dies eine Reihe von verschiedenen Arten geschehen gesehen, obwohl die beiden schlimmsten Übeltäter ganz ähnlich waren.

Der Webservice

Die erste Anwendung, eine Web-Service bietet Zugang zu einem potenziell hohen Datenvolumen innerhalb einer SQL-Datenbank. Beim Start zieht es mehr oder weniger all diese Daten aus der Datenbank und speichert sie im Speicher als XML. (Dreimal). Die Besitzer dieser Anwendung nennen es einen Cache. Ich nenne es langsam, weil jedes perf Problem, das in worden ist laufen, während sie gegen diese Arbeiten zu dieser Sache direkt nachvollziehbar war. (Es ist eine Unternehmensumgebung zu sein, sollte es nicht überraschen, dass der Kunde für das perf Versagen verantwortlich gemacht wird, nicht der Service.) Diese Anwendung funktioniert den XML DOM verwenden.

Der Importeur

Die zweite Anwendung liest eine XML-Datei, die als Ergebnis einer Ausfuhr aus einem Dritt Datenbank generiert wurde. Das Ziel ist, diese Daten in einem proprietären System zu importieren (im Besitz von uns). Die Anwendung, die tut es die gesamte XML-Datei liest und hält mindestens zwei, manchmal sogar vier Kopien der XML-Datei über die gesamte Import-Sequenz. Beachten Sie, dass die Daten manipuliert werden, transformiert und Konfiguration auftreten können, bevor der Import stattfindet, so dass der Importeur diese Daten in einem XML-Format besitzt es gesamte Lebensdauer ist. Es überrascht nicht, explodiert dieser Importeur dann, wenn eine mittelgroße XML-Datei zur Verfügung gestellt. Diese Anwendung verwendet nur die XML-DOM für eine seiner Kopien, der Rest sind alle rohen XML-Strings.

Mein Verständnis von gesundem Menschenverstand legt nahe, dass XML ist nicht ein gutes Format für Daten im Speicher zu halten, sondern Daten sollte in XML übersetzt werden, wenn es ausgegeben wird / übertragen und übersetzte in der internen Datenstrukturen wenn lesen und importiert. Die Sache ist, ich bin in der Produktion Code ständig laufen, die die Skalierbarkeit Probleme völlig ignoriert, und gehen durch einen ton zusätzlichen Aufwand, dies zu tun. (Die schiere Menge von String-Parsing in diesen Anwendungen ist erschreckend.)

Ist dies ein weit verbreitetes Versagen das richtige Werkzeug für den Job zu bewerben, dass andere Menschen in alos laufen? Oder ist es einfach nur Pech auf meiner Seite? Oder bin ich dabei etwas blendend klar und gut Situationen, in denen es richtig und in Ordnung ist, zu speichern große Mengen an Daten im Speicher als XML?

War es hilfreich?

Lösung

Alle gespeicherten Daten sollten in den Klassen sein. Die höheren Datenvolumen wir reden, desto wichtiger wird. XML ist ein enorm aufgebläht Format, das die Leistung reduziert. Xml sollte nur zum Umfüllen von Daten zwischen Anwendungen verwendet werden. IMHO.

Andere Tipps

Nein, ich bin einverstanden. Für Ihre erste Beispiel sollte die Datenbank behandeln fast alle Caching, so die Speicherung aller Daten im Programmspeicher ist falsch. Dies gilt, ob es sich im Speicher als XML gespeichert oder auf andere Weise.

Für die zweite, sollten Sie die XML in eine nützliche Darstellung konvertieren so schnell wie möglich, wahrscheinlich eine Datenbank, dann mit ihm arbeiten auf diese Weise. Nur wenn es sich um eine kleine Menge an Daten ist es zweckmäßig wäre, alle Arbeiten im Speicher als XmlDocument zu tun (zum Beispiel unter Verwendung von XPath). String-Analyse sollte sehr sparsam verwendet werden.

@Matthew Flaschen macht einen großen Punkt. Ich möchte hinzufügen, dass, wenn Sie ein vorhandenes Projekt teilnehmen, werden Sie wahrscheinlich einige Design und Implementierung Entscheidungen zu finden, die Sie nicht einverstanden mit.

Wir alle lernen neue Dinge die ganze Zeit und wir alle machen Fehler. Obwohl ich damit einverstanden, dass dies wie eine „duh“ Art von Problem scheint, ich bin sicher, dass die anderen Entwickler den Code durch das Konzept eines Cache zu optimieren versuchen.

Der Punkt ist, manchmal dauert es einen sanften Ansatz, Menschen zu überzeugen, vor allem Entwicklern, ihre Gewohnheiten zu ändern. Dies ist keine Codierung Problem, sondern ein Problem Mensch. Sie müssen einen Weg finden, diese Entwickler davon zu überzeugen, dass diese Änderungen nicht vorschlagen, implizieren sie inkompetent sind.

Ich würde vorschlagen, mit ihnen überein, dass Caching eine gute Idee sein kann, aber dass Sie die Funktionen beschleunigen möchten darauf zu arbeiten. Erstellen Sie eine kurze Demo, wie Sie Ihre (Weg logische) Implementierung arbeitet mit der alten Art und Weise verglichen. Es ist schwer, mit dramatischen Verbesserungen in der Geschwindigkeit zu argumentieren. Nur vorsichtig sein, um direkt auf die Art und Weise angreifen sie im Gespräch umgesetzt. Sie müssen diese Personen mit Ihnen arbeiten.

Viel Glück!

Ich bin damit einverstanden, wie gut, und ich denke, es ist ein Element von Pech.

... aber für Strohhalmen greifen, die nur den Einsatz kann ich für Daten sieht gespeichert werden als XML für die automatisierten Unit-Tests ist, wo XML eine einfache Möglichkeit, Daten Mock-up-Test zur Verfügung stellt. Auf jeden Fall lohnt sich nicht, though.

Ich habe festgestellt, dass ich es hätte zu tun mit einem Legacy-COM-Objekt zu interagieren. Das COM-Objekt kann entweder XML oder nehmen Sie eine Klasse. Der Interop-Overhead jedes Mitglied der Klasse zu füllen war viel zu groß und die Verarbeitung von XML war eine viel schnellere Alternative. Wir könnten ein c # -Klasse identisch mit der COM-Klasse gemacht, aber es war wirklich zu schwierig in unserem Zeitrahmen zu tun. So xml es war. Nicht, dass es immer eine gute Design-Entscheidung sein würde, aber wenn sie mit Interop für riesige Datenstrukturen zu tun, es war die schnellst wir tun konnten.

Ich muß sagen, dass wir LinqtoXML auf der C # Seite verwenden, so macht es etwas einfacher, mit zu arbeiten.

was ist OOP und Datenbanken? Xml hat seine Verwendungen, aber es kann Probleme (wie Sie sehen) mit ihm für alles verwendet wird.

Datenbanken für die Indizierung erlauben können, Transaktionen, etc., die Ihren Datenzugriff beschleunigen

Die Objekte sind in den meisten Fällen einfacher, mit zu arbeiten, Sie geben ein besseres Bild von Ihrer Domain, etc.

Ich bin nicht gegen xml verwenden, aber es ist wie Muster, sie sind ein Werkzeug, die wir verstehen, wo und wann sie verwendet wird, nicht in Liebe mit ihnen fallen und versuchen, sie überall zu verwenden ...

Greg,

in mehreren Anwendungen Ich habe folgen mehr oder weniger genau das Muster, das Sie beschreiben:

Edit: kein Kratzer, dass. Ich habe nie die XML als String (oder mehrere Strings) gespeichert. Ich analysierte es nur in einen DOM und arbeitete mit dem. DAS war hilfreich.

Ich habe Quellen in das DOM (Microsoft Parser) XML importiert und hielt sie dort für alle erforderlichen Verarbeitung. Ich bin mir sehr wohl bewusst, den Speicher-Overhead des DOM verursacht, aber ich fand ganz im apporach nützlich dennoch.

  • Einige Kontrollen während der Verarbeitung benötigen direkten Zugriff auf die Daten. Die selectPath Anweisung funktioniert recht gut für diesen Zweck.

  • DOM-Knoten hin und her in der Anwendung als Argumente übergeben werden kann. Die Alternative ist das Schreiben Klasse jeden einzelnen Objekttypen Verpackung und Aktualisieren von ihnen als das XML-Schema entwickelt. Es ist ein armes (VB6 / VBA) Mann Ansatz zur Polymorphismus.

  • eine XSLT-Transformation auf alle oder Teile des DOM Anwendung ist ein Kinderspiel

  • Datei-I / O-Pflege durch das DOM genommen zu (xmldoc.save ...)

Eine verknüpfte Liste von Objekten, würde eine vergleichbare Menge an Speicher verbrauchen und mehr Code benötigen. Alle Such- und E / A-Funktionalität müsste ich mich codieren.

Was ich als anti-Muster wahrgenommen wird, ist tatsächlich eine ältere Version der Anwendung, wo die XML wurde mehr oder weniger von Hand in Arrays von Strukturen analysiert.

Für hohe Datenmengen sind die Antwort nein, gibt es nicht gute Gründe, um Daten zu speichern direkt als XML-Strings im Speicher.

Hier ist jedoch eine interessante Präsentation , von Alex Brown, wie in einer effizienteren Weise XML in Erinnerung zu bewahren. Als 'Gefrorener Strom'.

Es gibt auch ein Video von diesem und anderen Präsentationen auf XML Prag gegeben 2009 hier .

Linktext

Im Allgemeinen würde ich versuchen, ein internes Datenmodell zu verwenden, die von seiner Serialisierung in XML unabhängig ist.

Doch meiner Meinung nach gibt es einen Fall, in dem als interne Datenstruktur unter Verwendung von XML macht Sinn : Wenn Ihr Datenmodell hierarchische Beziehungen erfassen muss, deren Format durch dritte Parteien verlängert werden kann, und wenn Ihr Anwendung benötigt diese Daten zu übermitteln, während die erweiterte Informationen zu erhalten.

Nehmen wir zum Beispiel Rahmen Lumberjack Logging: Die Idee ist ein XML-basiertes Ereignisdaten haben Modell, bei dem jede Anwendung hierarchische Informationen über Ereignisse zur Verfügung stellen kann (Warnungen, Fehler, etc.). Das Framework kümmert sich um die Ereignisse zu sammeln und sie an die entsprechenden Handler zu verteilen. Eine dritte Partei kann ihre eigenen Ergänzungen in das Format leicht definieren, und bietet entsprechende Generatoren und Handler.

Der wichtige Teil hier ist, dass der Rahmen für die XML mit allen XML-Informationen intakt aus dem Generator zu einem Handler weiterleiten muss. In diesem Fall eine interne Datenstruktur der Umsetzung, die selbst alle notwendigen Informationen führt zu einer erneuten Durchführung der meisten XML einfängt. Damit eine entsprechende DOM Rahmen für die interne Datendarstellung mit Sinn macht.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top