Laden...

Daten für Playlist-Verwaltung wie am besten (zwischen)speichern?

Erstellt von PoWl vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.538 Views
P
PoWl Themenstarter:in
219 Beiträge seit 2008
vor 6 Jahren
Daten für Playlist-Verwaltung wie am besten (zwischen)speichern?

Hi,

ich würde gerne eine Playlistverwaltung in C# schreiben, welcher über eine API mit einem Musikstreamingdienst in Verbindung steht und dort z.B. automatisch neue Releases von Künstlern in spezifische lokal im Programm gespeicherte Playlists einsortiert.

Diese Playlists muss ich nun natürlich in Form von Tabellen in meiner Software abbilden. Im einfachsten Fall würde ich hier einfach Klassen und Listen verwenden. Jedoch muss ich sicherstellen, dass nicht nur nach Beendigung der Software der aktuelle Programmzustand lokal auf dem Rechner zwischengespeichert wird sondern auch zwischendurch immer mal wieder, falls es zum Absturz der Software oder des Computers kommt, ohne dass zuvor gespeichert wurde.

Je nach Nutzungsgrad der Software stelle ich es mir nicht gerade performant vor, nach jedem Arbeitsschritt die gesamten Datenobjekte zu serialisieren und in eine Datei reinzuspeichern. Abgesehen davon, was wohl passiert, wenn während des Schreibvorgangs der PC mal abstürzt und damit die Datei hinüber ist. D.h. ich möchte also dass der aktuelle Programmzustand permanent live mit einer Art Datenbank synchronisiert wird so dass ich nach einem Softwareabsturz einfach alles wieder laden kann und genau da weitermachen kann, wo ich zuvor aufgehört hatte. Idealerweise würde hierbei die Synchronisation mit meinen Datenobjekten völlig automatisch funktionieren oder ich würde innerhalb meines Programms einfach direkt mit der Datenbank kommunizieren (ohne dass alle Daten in Form von Objekten permanent im RAM vorgehalten werden)

Welche Technik/Strategie eigent sich hierfür? Auf eine getrennt zu installierenden Datenbankserver bzw. generell Zusatzsoftware würde ich gerne verzichten. Empfiehlt sich vielleicht sogar eine Access-Datenbank? Oder so etwas wie SQlite? Bei der Fülle an Möglichkeiten fehlt mir irgendwie der Überblick 🤔 Wünschenswert wäre am Ende auch ein Format, das es zulässt, die Daten hinterher noch mit externer Software darstellen/bearbeiten zu können, was z.B. für XML oder eine Access-Datenbank sprechen würde.

lg Paul

1
124 Beiträge seit 2012
vor 6 Jahren

Also eigentlich hast du schon die beste Lösung genannt.

Es ist natürlich immer eine Frage des Aufwandes den man betreiben möchte/muss.
Am besten ist es natürlich eine lokale Datenbank die aber auch Online synchronisiert wird, falls die festplatte mal "stirbt".

Aber ich würde es lokal in eine Datenbank speichern und gut ist.
Datenbank hat den Vorteil, das nicht immer alles schreiben musst sondern nur die geänderten Einträge. Daher ist ein Datenverlust relativ gering.

Gruß Thomas

16.806 Beiträge seit 2008
vor 6 Jahren

Ich fürchte, dass Performance hier nicht Dein ausschlaggebendes Kriterium sein wird.
Eine Serialisierung zB. von Json in Dateien wird erst bei einer dreistelligen MB-Größe in Sachen Performance bei solchen Anwendungen/kleinen Tools relevant.
Und um in diese Datenregion zu kommen, musst Du verdammt viel speichern.

Ansonsten kann man auf die Frage einfach mit: "na, wie wärs mit einer Datenbank?" antworten 😉

Access eignet sich dafür nie. NIE NIE NIE NIE. NICHTS spricht für Access. NICHTS.
Ja, SQlite schon eher.

T
2.219 Beiträge seit 2008
vor 6 Jahren

Bei deinen Anforderungen würde ich direkt zu Sqlite raten.
Wenn du ganz sicher gehen willst, dass deine DB nicht durch einen Schreibvorgang bei einem Stromausfall beschädigt wird, kannst du auch regelmäig Backups durch einfaches Kopieren der DB anfertigen.
Dies sollte deine Anforderungen eigentlich komplett abdecken.
Performance von Sqlite dürfte kein Problem sein, wenn du deine DB Struktur sauber umgesetzt ist und auch entsprechend Indizies an den richtigen Stellen zum Einsatz kommt.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

P
PoWl Themenstarter:in
219 Beiträge seit 2008
vor 6 Jahren

Ich fürchte, dass Performance hier nicht Dein ausschlaggebendes Kriterium sein wird.
Eine Serialisierung zB. von Json in Dateien wird erst bei einer dreistelligen MB-Größe in Sachen Performance bei solchen Anwendungen/kleinen Tools relevant.

Dass ich das wahrscheinlich nicht mal merke wenn ich da mal meine 1MB Daten kurz auf meine SSD schreibe habe ich mir schon gedacht. Aber das passiert dann halt quasi jedes mal, wenn ich auch nur irgend eine Aktion mit einem Musik-Titel ausführe, und wenn es nur ist, z.B. eine Checkbox anzuklicken um den Titel irgendwie für irgendetwas zu markieren. Das erscheint mir doch irgendwie amateurhaft. Also dann wohl eher Datenbank.

Access eignet sich dafür nie. NIE NIE NIE NIE. NICHTS spricht für Access. NICHTS.
Ja, SQlite schon eher.

Aber ist MS Access nicht genau für solche Zwecke da? Eine relationale Datenbank in Form einer einzigen Datei lokal auf dem Rechner vorzuhalten und darüberhinaus in Form der Software "Microsoft Access" noch ein komfortables Userinterface zur Verwaltung dieser Datenbank bereitzustellen? Oder muss hierfür Access immer auch auf dem Rechner installiert sein und mein Programm ist hier auf externe Programm-Logik angeweisen?

SQlite ist ja dann quasi das gleiche. Hier halte ich natürlich auf jeden Fall die ganze SQlite-Logik in meiner Software vor und kann mit externen Tools meine Datenbankdatei laden und anschauen.

Gibt es sonst noch etwas zu beachten?

Wenn du ganz sicher gehen willst, dass deine DB nicht durch einen Schreibvorgang bei einem Stromausfall beschädigt wird, kannst du auch regelmäig Backups durch einfaches Kopieren der DB anfertigen.

Guter Punkt. Das würde in jedem Fall helfen.

16.806 Beiträge seit 2008
vor 6 Jahren

Aber ist MS Access nicht genau für solche Zwecke da?

NEIN.

Access hat in der .NET Welt nichts zu suchen.

2.078 Beiträge seit 2012
vor 6 Jahren

Im Prinzip wurde ja schon alles gesagt.

Die performanteste Art, diese Form von Daten permanent zu speichern, ist und bleibt eine Datenbank. Am einfachsten sind wohl SQLite oder LocalDB, wobei LocalDB mit EntityFramework etwas besser funktioniert - glaube ich zumindest. Jedenfalls sind es beides Datenbanken, die auf einer Datei basieren. Daneben nutzt Du dann ein ORM wie das EntityFramework, das kümmert sich dann auch gleich darum, dass nur so viel gespeichert wird, wie geändert wurde - wieder eine kleine Zeitersparnis.

Von außen nutzbar ist die Datenbank auch, solange dein Datenbank-Layout halbwegs vernünftig aufgebaut ist und die Gegenseite Zugriff auf die Datei hat.
Du kannst natürlich auch eine API schreiben und behältst damit die Kontrolle, wie die Daten genau geschrieben werden, schränkst mögliche andere Nutzer aber gleichzeitig damit an. Außerdem wird so eine API schnell schnell sehr aufwändig.

Eine 100%-Sicherheit, dass die Daten bei einem Festplatten-Crash nicht verloren sind, hast Du aber nie. Wenn die Festplatte genau in dem Moment stirbt, wenn die Änderungen in die Datenbank geschrieben werden, hast Du im schlimmsten Fall eine unbrauchbare Datenbank. Das passiert aber wenn dann nur jedes 3te Schaltjahr, wenn alle Planeten des Sonnensystems in einer Reihe stehen - also eher unwahrscheinlich 😄
Für den Fall der Fälle tut's aber auch ein Copy&Paste auf die Datenbank-Datei. Das kannst Du ja bei jedem Schließen des Programms machen, die paar MB, die die DB groß sein wird, sind schnell kopiert. Vergiss aber nicht, alte Backups zu löschen, denn 2000 Backups mit je 5MB sind trotzdem 10GB 😄

Ach und wegen Access:
Das was Access kann, gibt's auch in Form von anderen Programmen, nur dass die dann mit einer richtigen Datenbank sprechen können. Oder Du bastelst einen eigenen Bereich in dein Programm ein, der es erlaubt, die Rohdaten zu bearbeiten - würde ich aber ehrlich gesagt nicht machen.

Wenn Du unbedingt ein externes Programm für deine Daten haben willst, dann solltest Du einen Excel-Export bzw. Import einbauen, irgendwann hat jeder schon mal mit Excel gearbeitet. Wenn Du das direkt mit xlsx machst, hast Du viele Möglichkeiten, es ist aber auch komplizierter. Einfacherer wäre ein CSV-Dokument (Such mal nach CSVHelper, das macht das praktisch automatisch), dann musst Du bloß darauf achten, dass Excel beim öffnen keine Daten kaputt interpretiert.
So ein Excel-Export bzw. Import finde ich persönlich immer ganz schön, weil man in Excel oft sehr viel einfacher und schneller viele Daten bearbeiten kann als in dem eigentlichen Programm.
Außerdem hast Du bei dem Import die Kontrolle darüber, wie die Daten in die Datenbank geschrieben werden, das hast Du nicht, wenn jemand direkt in deiner Datenbank schreibt.

By the way:
Wofür ist Access eigentlich gut?
Soweit ich mich erinnere, bietet es nur eine ganz nette grafische Oberfläche für irgendetwas,
was ODBC implementiert. Also nicht mehr als das, was andere Programme auch mit einer echten Datenbank können.

P
PoWl Themenstarter:in
219 Beiträge seit 2008
vor 6 Jahren

Alles klar. Danke für die Antworten!

Ich denke ich werde mich dann mal mit SQlite beschäftigen, das scheint genau das zu sein, was ich brauche 🙂

Eine eigene API möchte ich nicht schreiben, das Tool selbst wird schon genug Arbeitsaufwand mit sich bringen, da muss das Drum-Rum einfach sitzen sonst steh ich am Ende ganz ohne Ergebnis da, man kennt das. 😁

H
523 Beiträge seit 2008
vor 6 Jahren

By the way:
Wofür ist Access eigentlich gut?
Soweit ich mich erinnere, bietet es nur eine ganz nette grafische Oberfläche für irgendetwas,
was ODBC implementiert. Also nicht mehr als das, was andere Programme auch mit einer echten Datenbank können.){gray}

Man hat eine _Datenbank _und vollständiges VBA inkl. eines Formulargenerators in Access, so dass man eigene Anwendungen schreiben kann. Ich kenne einige Firmen die sich ihre ganzen Warenwirtschaft in Access geschrieben/zusammengefummelt haben.

Man kann SQL-Abfragen mit einer UI zusammenklicken. Es lassen sich (via) ODBC auch Daten anderer Datenbanken anzeigen, ändern und vieles mehr.

Ich persönlich komme eigentlich nur noch bei Datenübernahmen aus Fremdsystemen in Kontakt mit Access.