Speichern von Einstellungen: XML vs. SQLite?

Question

Ich schreibe gerade einen IRC-Client und habe versucht, eine gute Möglichkeit zum Speichern der Servereinstellungen zu finden. Im Grunde eine große Liste von Netzwerken und deren Servern wie die meisten IRC-Clients haben.

Ich hatte mich für SQLite entschieden, aber dann wollte ich die Liste im XML-Format (und vielleicht endgültig) online frei verfügbar machen, damit andere IRC-Anwendungen sie nutzen können. Jetzt werde ich die Einstellungen vielleicht einfach lokal in demselben Format speichern.

Ich habe sehr wenig Erfahrung mit ADO.NET oder XML, so dass ich nicht sicher bin, wie sie in einer Situation wie dieser vergleichen würde.

Ist es einfacher, mit einem Programm zu arbeiten? Ist eine schneller? Spielt das eine Rolle?

Answer 1

Diese Frage ist unklarer als Sie denken. Unter "Einstellungen" kann man eine ganze Menge verstehen.

Es gibt eine gute .NET-Infrastruktur für die Handhabung von Anwendungseinstellungen in Konfigurationsdateien. Diese werden im Allgemeinen Ihrem Programm als Eigenschaften eines globalen Settings-Objekts angezeigt; die Klassen in der System.Configuration Namespace kümmern sich um das Lesen und Persistieren, und es gibt in Visual Studio integrierte Tools, die den Code für den Umgang mit ihnen automatisch generieren. Einer der Datentypen, die diese Infrastruktur unterstützt, ist StringCollection so dass Sie damit eine Liste von Servern speichern können.

Aber für eine große Liste von Servern wäre dies aus mehreren Gründen nicht meine erste Wahl. Ich gehe davon aus, dass die Elemente in Ihrer Liste Tupel sind (z.B. Hostname, Port, Beschreibung) und nicht einfache Strings. In diesem Fall müssen Sie die Daten formatieren und parsen, um sie in eine StringCollection und das ist im Allgemeinen ein Zeichen dafür, dass Sie etwas anderes tun sollten. Außerdem sind Anwendungseinstellungen schreibgeschützt (zumindest unter Vista), und obwohl Sie einer Einstellung einen Benutzerbereich geben können, um sie persistent zu machen, führt Sie das auf einen Weg, den Sie wahrscheinlich verstehen möchten, bevor Sie ihn einschlagen.

Das ist eine weitere Sache, die ich in Betracht ziehen würde: Ist Ihre Serverliste einfach nur eine Liste, oder haben Sie ein internes Objektmodell, das sie repräsentiert? Im letzteren Fall würde ich eine XML-Serialisierung zum Speichern und Abrufen der Objekte in Betracht ziehen. (Das Einzige, was ich in der Anwendungskonfigurationsdatei behalten würde, wäre der Pfad zu der serialisierten Objektdatei.) Ich würde dies tun, weil die Serialisierung und Deserialisierung von einfachen Objekten in XML wirklich einfach ist; Sie müssen sich nicht mit dem Entwurf und dem Testen eines geeigneten Serialisierungsformats befassen, da die Tools dies für Sie erledigen.

Der Hauptgrund, warum ich eine Datenbank verwende, ist, wenn mein Programm eine Reihe von Operationen durchführt, deren Ergebnisse atomar und dauerhaft sein müssen, oder wenn ich aus irgendeinem Grund nicht alle meine Daten gleichzeitig im Speicher haben möchte. Wenn ich jedes Mal, wenn X passiert, eine dauerhafte Aufzeichnung davon haben möchte, dann führt mich das in die Richtung, eine Datenbank zu verwenden. Die XML-Serialisierung ist für so etwas in der Regel nicht geeignet, da man realistischerweise nicht nur ein Objekt serialisieren kann, wenn man alle seine Objekte in einer einzigen physischen Datei speichert. (Obwohl es sicherlich nicht verrückt ist, einfach das gesamte Objektmodell zu serialisieren, um eine Änderung zu speichern. Genau das macht das Produkt meines Unternehmens, und das weist auf einen weiteren Umstand hin, unter dem ich keine Datenbank verwenden würde: wenn sich das Schema der Daten häufig ändert).

Answer 2

Ich persönlich würde XML für Einstellungen verwenden - .NET ist bereits dafür ausgelegt und verfügt über viele integrierte Funktionen zum Speichern Ihrer Einstellungen in XML-Konfigurationsdateien.

Wenn Sie ein benutzerdefiniertes Schema (sei es XML oder DB) für die Speicherung von Einstellungen verwenden möchten, dann würde ich sagen, dass entweder XML oder SQLite genauso gut funktionieren wird, da Sie eine anständige API rund um den Datenspeicher verwenden sollten.

Answer 3

Jedes Werkzeug hat sein eigenes Recht

Der Hype um XML ist groß, ich weiß. Aber Sie sollten sehen, dass XML im Grunde ein Austauschformat ist - kein Speicherformat (es sei denn, Sie verwenden eine systemeigene XML-Datenbank, die Ihnen mehr Möglichkeiten bietet - aber auch einige Kopfschmerzen bereiten kann).

Wenn Ihre Konfiguration eher klein ist (z.B. weniger als 10.000 Datensätze), können Sie XML verwenden und haben keine Probleme. Sie laden das Ganze in Ihren Speicher und greifen dort auf die Einträge zu. Erledigt.

Aber wenn Ihre Konfiguration so groß ist, dass Sie sie nicht komplett laden wollen, dann überdenken Sie Ihre Entscheidung und bleiben bei SQLite, das Ihnen die Möglichkeit bietet, die Teile der Konfiguration, die Sie benötigen, dynamisch zu laden.

Sie könnten auch ein kleines Tool bereitstellen, um eine XML-Datei aus dem DB-Inhalt zu erstellen - die Erstellung von XML aus einer DB ist eine recht einfache Aufgabe.

Answer 4

Es sieht so aus, als hätten Sie hier zwei getrennte Anwendungen: einen Webserver und einen Desktop-Client (denn dort laufen diese Dinge üblicherweise), die jeweils ihren eigenen Speicherbedarf haben.

Auf der Serverseite: Verwenden Sie einen relationalen Datenspeicher, kein Xml. Grundsätzlich müssen Sie irgendwann Benutzerdaten von anderen Benutzerdaten auf dem Server getrennt halten. XML ist kein guter Speicher dafür.

Auf dem Client: Es spielt keine Rolle. Xml wird für Sie wahrscheinlich einfacher zu handhaben sein. Und denken Sie nicht, dass Sie eine Technologie, die Sie in einer Umgebung verwenden, auch in einer anderen verwenden müssen.