C# Eigene Liste per "List<T> Class System" erstellen

[Nichael-E]

Guten Tag
hat man vor in C# eine kleine DB zu erstellen (also so in einer Größe von ~100 Einträgen), wie würdet Ihr da so vorgehen?

Idee:
Die 1. Idee, die ich da so hätte (aber NOCH nicht so umsetzen kann, wie Ihr es machen würdet), wären Listen. Also solche wie das List<T> Class System. Richtig? Arrays (zum Beispiel HIER sehr gut erklärt)? Glaube das wäre für diesen Zweck nicht so das wahre. Also was ich da in den letzten Wochen so gelsesen habe, ist die Tatsache, das Listen eine wesentliche bessere Form von Array sind und diese nach Belieben entweder vergrößert oder verkleinert oder aber auch gelöscht werden können. Also wäre dieser Punkt doch schon mal geklärt, auch richtig?

Einsatz: Sagen wir mal als Beispiel den Einsatz einer Liste über das Periodensystem
Entwurf: Wenn ich bis jetzt richtig liege (wäre schon ein Meilenstein für mich ) dann würde ich so vorgehen...

using System;
using System.Collections.Generic;

class Element
    {
        public string Symbol { get; set; }
        public string Name { get; set; }
        public int AtomicNumber { get; set; }
        public double Atommasse { get; set; }
        public string Period { get; set; }
        public string Group { get; set; }
        public int Ordnungszahl { get; set; }
       // Das sollte reichen!
    }

    class Program
    {
        static void Main()
        {
            Elemente = new List<Element>(); // Elemente zufügen

            // Weitere Elemente und Daten hinzufügen...
            Elemente.Add(new Element { Ordnungszahl = 1, Symbol = "H", Name = "Wasserstoff", Atommasse = 1.008 });
            Elemente.Add(new Element { Ordnungszahl = 2, Symbol = "He", Name = "Helium", Atommasse = 4.0026 });
            // Da fehlt noch einiges!!!
        }
    }
}

Nun meine Frage...:
1. Wäre der Ansatz so in etwa korrekt? Glaub ich eigentlich nicht so, denn danach, was ich so geslesen habe, muss das ein verdammt komplexer Vorgang sein.

2. Es gäbe ja noch einen Weg per SQL Einbindung in VS. Aber so weit bin ich ja noch nicht. Vor allem braucht man SQL ja erst so ab 1000-senden von Einträge.

Hab in den letzten Wochen mehr als genug über Methoden und Operanden gelesen, wobei bei Boolschen Operanden mir fast der Kopf geplatzt wäre. Echt heftig Aber Rom wurde ja auch nicht an einem Tag erbaut

 

[eweu]

Schau dir mal SQLite an. Für C# könnte LINQ auch interessant für dich sein.

 

[abcddcba]

Vor allem braucht man SQL ja erst so ab 1000-senden von Einträge.

SQL ist nur ein Anfragesprache fuer relationale Datenbanken - das brauchst du genau dann wenn du deren Ausdrucksmaechtigkeit benoetigst. Mit der Groesse hat das pauschal mal nix zu tun.

Bisher hast du eine Liste von Objekten. Jetzt ist die Frage was du damit machen willst? Abfragen? Wenn ja was genau? Von eine (klassischen) DB bist du da noch weit weg, aber evtl. brauchst du auch nur eine Liste. Und keine Indexstrukturen, Transaktionen etc.

 

[HighDev]

Das kann man schon so machen. Du kannst in C# auch Listen mit ca. 2,4 Mia Einträgenhaben, das ist erstmal kein Problem. Die Daten liegen dann halt nur im Arbeitspeicher, beendest du das Programm, ist alles weg. Wenn du dann also die Daten behalten willst, kommt erst eine DB ins Spiel. Man kann sowas aber auch per Serialisierung lösen, dann spukt das Programm eine Datei aus, in der die Elemente alle stehen. Beim Start des Programms müssen diese dann eingelesen werden. Wird etwas gelöscht, geändert oder hinzugefügt, muss die Datei neu erzeugt werden.

Alternativ könnte man auch ein Dictionary verwenden (grob gesagt eine Liste aus Schlüssel und Wertepaaren), der Schlüssel könnte dann bspw die Ordnungszahl sein. So lässt sich bspw. verhindern, dass ein Element doppelt angelegt wird, da es jeden Schlüssel in einem Dictionary nur EINMAL geben darf.

 

[Raijin]

Du vermischt hier ein paar Begrifflichkeiten. Datenbanken sind Datenbanken (SQL ist dabei streng genommen nur die Definitions-/Abfragesprache) und Variablen wie Listen sind eben Variablen.

Variablen beinhalten pauschal ausgedrückt veränderliche Daten während der Laufzeit eines Programms. Wird das Programm beendet, sind die Variablen weg. Datenbanken sind sozuagen ein komplexer Dauerspeicher. Die Daten in einer Datenbanken sind unabhängig von deiner Anwendung und bleiben auch nach Beenden derselbigen erhalten.

Variablen enthalten also temporäre Informationen.
Datenbanken enthalten persistente Informationen.

Allerdings sind Datenbanken nicht das einzige Werkzeug, mit dem man persistente Daten vorhalten kann. Eine Datei wäre ein weiteres Beispiel. Um veränderliche Daten über mehrere Programmstarts hinweg zu erhalten, könnte man sie also in einer Datenbank ablegen, sei es ein vollwertiger SQL-Server wie zB MS SQL, MySQL, PostgreSQL (ich verzweifle an diesem Namen) oder eben eine Datendatei wie zB eine csv. Es gibt auch Hybriden wie von @eweu schon erwähnt wurde: SQLite. Das ist streng genommen nur eine Datei und eben kein Server, wird aber ebenfalls mit SQL als Sprache verwaltet.


Das entscheidende bei Datenbanken ist aber nicht unbedingt die bloße Speicherung von Daten, die man wie erwähnt auch mit anderen Mitteln wie csv-Dateien erreichen könnte, sondern insbesondere der effiziente Abruf der Daten. In Datenbanken kann man in Bruchteilen einer Sekunde den richtigen Datensatz suchen und ggfs verändern. Die Datenbank arbeitet beispielsweise mit schnell zu sortierenden und filternden Indizes und kann so mit nur wenigen Handgriffen zum gesuchten Datensatz kommen. Bei einer Textdatei liefe es effektiv darauf hinaus, dass die Datei von vorne an Byte für Byte durchsucht wird bis iiiiiiiiiiiirgendwann die richtige Zeile gefunden wurde.

Die Effizienz von Datenbanken kommt sicherlich erst ab einer gewissen Größenordnung an Daten wirklich zum Tragen, aber relationale Datenbanken, wie sie eigentlich heißen, zeichnen sich abgesehen von den effizienten Suchalgorithmen auch durch die namensgebenden Relationen aus. Dabei werden Datensätze unterschiedlicher Natur miteinander verknüpft. In einer Datenbank befindet sich also vereinfacht ausgedrückt nicht nur eine Tabelle, sondern Dutzende, Hunderte und mehr.

Nehmen wir mal ein klassisches Beispiel, ein Kegelverein. Es wird eine Liste von Mitgliedern samt Namen und Adressen geführt. Ehepartner haben natürlich - oder hoffentlich - dieselbe Adresse. Ziehen sie um, muss man die Adresse in zwei Zeilen ändern. In einer relationalen Datenbank läge die Adresse aber in einer separaten "Adressen" Tabelle und die dortigen Adressen wären in der "Mitglieder" Tabelle lediglich verknüpft - so auch bei den Ehepaaren, die dann dieselbe und zwar wirklich dieselbe Adresse hätten. Beim Umzug würde man die Adresse ein einziges Mal ändern und es würde für beide gelten. Dieses Szenario findet man in relationalen Datenbanken an allen Ecken und Enden wieder, etliche Male und teils auch über mehrere Verknüpfungen hinweg. Komplexe Daten eben und nicht nur eine banale Telefonliste mit Name und Telefonnummer.


Um auf dein Beispiel zurückzukommen: So wie du es gemacht hast, funktioniert es natürlich. Die Frage ist aber was du mit den Informationen nun anstellen möchtest. Das Periodensystem beinhaltet bekanntermaßen unveränderliche Daten, mal von neu er-/gefundenen superschweren Elementen am Ende abgesehen. Man könnte diese Daten also hard coded beim Start der Anwendung generieren, jedes Mal. Übertragen wir das Beispiel aber auf eine Mitgliederliste wie oben angerissen, sprächen wir über veränderliche Daten, weil Mitglieder kommen und gehen. Eine hart codierte Mitgliederliste wäre aus nachvollziehbaren Gründen denkbar ungünstig. Hier würde also mindestens eine banale Textdatei ins Spiel kommen - oder eine Datenbank, sei es als Server oder in einfacher Form mit SQLite, o.ä.

 

[f00bar]

Ich halte dieses kleine Projekt ebenfalls für durchaus geeignet, sich direkt auch mit den Grundlagen der Datenspeicherung zu befassen. Ob jetzt als Textdatei, als JSON, als XML oder gleich als SQL ist im Grunde egal; wenn du einen generischen Datentyp hinbekommst, wirst du an einfachem SQL eher nicht scheitern. Es handelt sich um eine überschaubare Datenmenge aus unveränderlichen Daten, wie Raijin so wunderbar erläutert hat - das bedeutet in deinem Fall erst einmal, dass du dir um die Struktur der Datenbank (oder des Speichersystems) nicht allzuviele Gedanken machen musst. Mit SQL zum Beispiel kannst du wohl am einfachsten (und effizientesten) so eine Art Suche einbauen, mit der man etwa nach einer Ordnungszahl suchen kann und das Element zurückgeliefert bekommt. Oder aber eine Art Filterlösung, die dir meinetwegen alle Elemente mit Atommasse zwischen x und y liefert - als "Fingerübung" ist das alles nicht schlecht.

Befasse dich ruhig einmal mit SQL, SQLite wird für den Anfang absolut ausreichen und ist einfach einzurichten. Von Datenspeicherung in der App halte ich persönlich nichts.

 

[Nichael-E]

...sich direkt auch mit den Grundlagen der Datenspeicherung zu befassen. ...Befasse dich ruhig einmal mit SQL, SQLite wird für den Anfang absolut ausreichen und ist einfach einzurichten.

Hatte ich mir auch schon gedacht, aber ich bin halt neugierig und vor allem die Tatsache, dass ich schon ne Menge über die Listen gelesen hab. Darum war ich halt so neugierig.

Ich kenne und befasse mich seit 2005 mit SQL damit, seit dem ich ein eigenes VB Forum habe. Klar, SQL ist ne eigene Sprache für sich und machmal ziemlich kompliziert und man muss sich schon schlau machen, wenn man etwas nicht weiß. Aber seit einigen Monaten auch keine Lust mehr darauf gehabt, seit ich C# als neue Leidenschaft entdeckt habe

Von Datenspeicherung in der App halte ich persönlich nichts.

Und genau das wollte ich ja auch wissen Trotzdem vielen Dank für die Hilfe!!!

Auch ein herzliches Danke schön an die anderen und Raijin für seine umfangreiche Information