struct oder class

[xerion21]

Hallo zusammen,

ich bin gerade dabei mal wieder ein kleines Programm zu schreiben, um mein Leben zu vereinfachen

Ich habe dazu folgende Frage:
Sollte ich lieber ein struct verwenden oder eine Klasse?

Hintergrund:
Es geht darum, dass ich Eingaben von einer GUI entgegennehmen muss. Das sind so an die 200 Daten.
Diese Daten sollen in Variabeln zwischengespeichert werden und dann in eine Datenbank gespeichert werden.

Diese Daten sollen verglichen werden und bearbeitet werden, sodass es sein kann, dass mehrere Instanzen aufgerufen werden.

Ich würde zu einer Klasse tendieren, da die Datenmenge nicht sonderlich groß ist.

Gruß

Xerion21

EDIT:
Habe noch eine Frage: Ist es sinnvoller das eine GUI eine Klasse/Struct aufruft, oder ein Struct/Klasse die GUI?

[cloidnerux]

Ich würde zu einer Klasse tendieren, da die Datenmenge nicht sonderlich groß ist.

In C# ist der unterschied in der tatsächlichen Größe der Instanzen von Structs und Classes nicht sonderlich groß.
Wichtiger ist, was konzeptionell besser passt. Struct ist in C/C++ nur ein Verbund an Variablen, in C# kann ein Struct noch mehr(Konstruktor, Operatorüberladung, Funktionen), damit ist man sowieso nicht mehr weit entfernt von der Klasse, siehe auch http://msdn.microsoft.com/de-de/library ... s.71).aspx

Von daher, nimm ne Klasse.

Das sind so an die 200 Daten.

200 sind nicht viel.

Diese Daten sollen in Variabeln zwischengespeichert werden und dann in eine Datenbank gespeichert werden.

Sinnvollerweise baut man sich eine Klasse, die einem Datensatz entspricht(Daher eine Zeile in einer relationalen Datenbank). Dann legst du dir eine Liste dieser Datensätze an, füllst sie mit werten und kannst diese dann per Iteration in deine DB schreiben.
Dabei kann man viele nette Extras in die Klasse integrieren, wie Datenprüfung, Operatorüberladung, foreach usw. Und mit LINQ kann man dann auch schön Datensätze auswählen:

Code: Alles auswählen

List<myData> data = new List<myData>();
[...]
var subList = data.where(x => x.id > 10 && x.id < 50);  //Alle Datensätze mit einer ID zwischen (10, 50)

[xerion21]

Sinnvollerweise baut man sich eine Klasse, die einem Datensatz entspricht(Daher eine Zeile in einer relationalen Datenbank). Dann legst du dir eine Liste dieser Datensätze an, füllst sie mit werten und kannst diese dann per Iteration in deine DB schreiben.
Dabei kann man viele nette Extras in die Klasse integrieren, wie Datenprüfung, Operatorüberladung, foreach usw. Und mit LINQ kann man dann auch schön Datensätze auswählen:

Die 200 Daten sind ein Datensatz einer Tabelle
Deswegen Frage ich nach.
Klar die Überprüfung muss eh nochmal stattfinden, bevor man die Daten absendet...

[cloidnerux]

Die 200 Daten sind ein Datensatz einer Tabelle

200 unterschiedliche Daten in einer Zeile?
Klingt irgendwie falsch

[xerion21]

ja


auf mehrere Spalten aufgeteilt natürlich
Aber vom Prinzip her.
Ein Datensatz würde aus 200 Daten bestehen

[cloidnerux]

auf mehrere Spalten aufgeteilt natürlich

Schon klar, aber 200 Spalten?

Hast du da vlt noch Probleme mit der Normalisierung(Datenbank Normalform)?
Klingt für mich danach, als würdest du in jeder Zeile die Daten jedes Bauteils eines Autos speichern

[xerion21]

Hast du da vlt noch Probleme mit der Normalisierung(Datenbank Normalform)?

Wie meinst du das?

Das Problem ist, es ist eine Datenbank über Spiele. In die müssen halt alle Informationen herein, die im Spiel stattgefunden haben. Ob Tore etc etc etc.
Inklusive Berichten und co.

[cloidnerux]

Das Problem ist, es ist eine Datenbank über Spiele. In die müssen halt alle Informationen herein, die im Spiel stattgefunden haben. Ob Tore etc etc etc.
Inklusive Berichten und co.

Dann ist wohl die Grundfrage, ob Struct oder Class hinfällig. So ein Datensatz ist natürlich etwas Aufwändiger zu Modellieren, um dynamisch damit zu Arbeiten.

Wie meinst du das?

Ich hatte das Grundkonzept von irgendwelchen relationalen Daten, die in ne MySQL Datenbank geschrieben werden und da hatte es mich verwundert, dass du 200(feste Anzahl) unterschiedliche Daten hast, die alle nur vom Primärschlüssel abhängen sollen.(Daten werden so gruppiert und auf Tabellen verteilt, dass sie nur vom Primärschlüssel abhängen).
Bei Fußball Daten ist das Datenvolumen pro Datensatz verständlich, die Frage ob dein Datenbank Modell sinnvoll ist, sollte woanders gestellt werden.

[xerion21]

Ich hatte das Grundkonzept von irgendwelchen relationalen Daten, die in ne MySQL Datenbank geschrieben werden und da hatte es mich verwundert, dass du 200(feste Anzahl) unterschiedliche Daten hast, die alle nur vom Primärschlüssel abhängen sollen.(Daten werden so gruppiert und auf Tabellen verteilt, dass sie nur vom Primärschlüssel abhängen).
Bei Fußball Daten ist das Datenvolumen pro Datensatz verständlich, die Frage ob dein Datenbank Modell sinnvoll ist, sollte woanders gestellt werden.

ja gut der Primärschlüssel würde der Spielnummer entsprechen, denn diese ist ja einmalig.

Dann ist wohl die Grundfrage, ob Struct oder Class hinfällig. So ein Datensatz ist natürlich etwas Aufwändiger zu Modellieren, um dynamisch damit zu Arbeiten.

und die Antwort wäre?

[cloidnerux]

ja gut der Primärschlüssel würde der Spielnummer entsprechen, denn diese ist ja einmalig.

Jop, aber deine Daten entsprechen dann nicht der 3.Normalform. Hier auch mal die Empfehlung, sich die Datenbank-Normalformen anzuschauen.

und die Antwort wäre?

Auf die selbe Art und weise wie deine Datenbank.

Du Hast ein Spiel, das ist einzigartig. An diesem Spiel nehmen 2 Mannschaften teil, diese sind auch Einzigartig für sich genommen. In diesem Spiel werden Besondere Aktionen durchgeführt, diese sind auch einzigartig für sich genommen.
Daher brauchst du mindestens 3 Tabellen: Spiele, Mannschaften, Ereignisse.
Die Tabelle Spiele besteht aus der ID, den IDs der beteiligten Manschaften, Ort, Nachspielzeit.
Die Tabelle Mannschaften besteht aus einer ID, Mannschaftsname und sonstige Mannschaftsparameter
Die Tabelle Ereignisse besteht aus der ID, der Spiel ID, einer Spieler ID der am Ereignis beteiligt war, der Art des Ereignisses(Tor, Foul, etc) und der Zeit im Spiel.