C# Desktop App - Format für Datenquelle? JSON? CSV? SQL DB?

[antaro]

Hallo Programmers,

ich plane eine C# Desktop Demo-App (.NET5/WPF/MVVM) als Frontend mit CRUD
für ca. 700 Datensätze. (8 Spalten)

Frage: Welches Format (mit wenig Aufwand) ist für die Datenquelle geeignet ?
JSON, CSV oder sollte es eine SQL DB sein ?

Eure Meinung dazu ?

Besten Dank
Antaro

 

[Bagbag]

Für 700 Datensätze kannst du ein Würfel rollen lassen und den entscheiden lassen...

Bei der Datenmenge ist das wirklich egal. Nimm das, was am einfachsten ist. Das wird wohl der XmlSerializer sein.

 

[antaro]

Das wird wohl der XmlSerializer sein.

Besten Dank für deine Antwort.
Ja XML ist auch eine Möglichkeit. Der Overhead bei XML nervt mich ein wenig. Ist XML noch immer up-to-date ?
Wie sieht es mit JSON aus? Je kleiner die Datendatei - desto besser.

 

[Bagbag]

Json ist natürlich auch möglich. Meine bevorzugte Bibliothek hierfür ist Newtonsoft.Json

Darüber dann noch bspw. gzip/deflate jagen.

Wenn minimale Dateigröße das absolute Ziel ist, kannst du auch mal binary serializer c# in Google eintippen. Hier dann zusätzlich natürlich auch wieder eine Komprimierung drüber jagen. Am besten zstd.

 

[rene87]

Für die Menge an Daten würde ich auch Jason benutzen. Bei unseren aktuellen Net 5 Projekten benutzen wir mittlerweile System.Text.JSON

 

[antaro]

Besten Dank für Eure Antworten.
Ich habe mich nun für JSON und die Newtonsoft Library entschieden (als ersten Versuch).

Sollte man heute noch Binärdateien als Datenquelle nutzen ?

 

[Bagbag]

Wenn Binärdaten für dein Ziel hilfreich sind und die Vorteile die Nachteile überwiegen, spricht nichts dagegen.

 

[Dalek]

Sobald es Ernst wird, eine Datenbank wie SQLite oder Postgres. Eine echte Datenbank hat sehr viele Vorteile und Fähigkeiten, gerade wenn es um robuste Speicherung und Konsistenz geht. Da kann man sehr viel falsch machen wenn man zu komplexe Sachen einfach in eine Datei selbst schreibt.

700 Datensätze ist Spielzeug, da ist von der Menge her völlig egal was man macht. Aber ich würde trotzdem einfach SQLite nehmen, da es nicht wirklich viel schwieriger ist als die Alternativen. Und der Nachteil der einfachen Lösung mit Datei ist das die Migration zu einer robusteren Variante dann viel Arbeit ist wenn man es braucht.

 

[Raijin]

Es kommt natürlich auch auf die Art bzw die Komplexität der Daten und den Zugriff auf selbige an. Wenn es nur eine Tabelle ist, spielt es bei 700 Datensätzen im Prinzip wirklich keine Rolle solange man nicht ständig wie ein Weltmeister die Datei hoch und runter beackert, weil man Datensätze sucht - wobei man ggfs die Datei beim Start natürlich auch komplett in den Speicher einlesen kann.
Sobald es aber mehrere Tabellen gibt, die untereinander verknüpft sind, bietet sich eine Datenbank natürlich an, ganz banal SQLite.

Man sollte auch darüber nachdenken wohin sich die Anwendung später mal entwickeln könnte. Das was Stand heute ausreicht, kann vielleicht schon nächste Woche zur Krücke werden. Man muss ja nicht unnötige Arbeit machen, um schon nach kurzer Zeit von einer Datei auf eine Datenbank umzubauen.

 

[RalphS]

Ich würde persönlich nur CSV aus der Liste der möglichen Optionen streichen wollen.

Ist einfach, klar. Aber es hält sich niemand wirklich an einen (Pseudo)Standard, den es in dem Sinne gar nicht gibt, und dann hat man hinterher mehr mit Sonderbehandlung von irgendwelchen Einzelfällen zu tun als daß man sich um das Problem an sich kümmenr könnte.

Alles was passabel strukturiert werden kann ist erstmal okay, wobei ich selber zugegeben wahrscheinlich auch zunächst in Richtung SQLite schauen würde.
Einfach um ein uniformes Interface verwenden zu können. SELECT a FROM b WHERE c geht mehr oder weniger immer.

 

[GroMag]

Einfach um ein uniformes Interface verwenden zu können. SELECT a FROM b WHERE c geht mehr oder weniger immer.

Da gibt es so ne nette Geschichte namens LINQ

 

[RalphS]

Ja sicher, aber verwechselst du das grad mit WQL? 🤔

Linq ist definitiv nett, aber es kommt auch später im Stack und wer nicht mit IEnumerable<T> arbeitet hat mehr Aufwand... sprich es gibt gewissen Overhead für linq selber und für die Nacharbeit.

Klar. Ein zwei eigene Extensions und dann flutscht es. Muß man sich mit anfreunden (können) daß man sich da sein OO etwas kaputt macht, und ob ~1000 Records das rechtfertigen mag ich auch nicht einschätzen, aber es geht und geht gut.

WQL auch. Ich stolper als sql Person über die Syntax- regelmäßig 😅 — aber geht.

Nur liegt beides weiter oben im Stack UND man muss .Net verwenden. Strukturierte Daten müssen schon da sein und da sind wir wieder bei Alles Außer Csv Weil Eben Nicht Strukturiert. 😉

 

[GroMag]

Ja sicher, aber verwechselst du das grad mit WQL?

Nein, ich meine explizit LINQ. Weil damit hat man SQL-like "ein uniformes Interface". (aber vllt reden wir auch grad aneinander vorbei)

 

[Drexel]

Vor einem halben Jahr hatte ich mit Microsofts Json Implementierung noch ein paar Probleme und bin deswegen auch wieder bei Newtonsoft gelandet... Ich glaub man konnte keine Felder sondern nur Properties serialisieren, kann das sein? Ist das immer noch so?

 

[Dalek]

Vor einem halben Jahr hatte ich mit Microsofts Json Implementierung noch ein paar Probleme und bin deswegen auch wieder bei Newtonsoft gelandet... Ich glaub man konnte keine Felder sondern nur Properties serialisieren, kann das sein? Ist das immer noch so?

Da gibt es viele Verbesserungen in .NET 5, und Felder serialisieren ist da dabei:

https://devblogs.microsoft.com/dotnet/whats-next-for-system-text-json/

 

[Drexel]

Gut zu wissen und gut, dass ich meine App gerade am Wochenende auf .NET 5 umgestellt habe, evtl geb ich dem beim nächsten Update mal einen Versuch...