C# Liste variabler Länge in MySQL Datenbank speichern

Hallo zusammen,

ich habe hier ein Objekt, dessen Daten (alles Strings) ich ich in einer MySQL Datenbank speichere. Das funktioniert auch soweit wunderbar, nur hat jetzt jedes Objekt auch noch eine Stringliste mit variabler Länge. Diese Liste würde ich nun auch gerne in der Datenbank speichern.
Allerdings fehlt mir momentan eine Idee, wie man das am geschicktesten macht.
Ich habe bisher noch nicht viel mit MySQL gemacht und hoffe deshalb, dass Ihr mir evtl. den ein oder anderen Tipp geben könnt
Achja, bei meinem Projekt handelt es sich um ein WPF Projekt.

Grüße
Mathias

edit

Du brauchst in deiner DB noch sowas wie eine 1:N Beziehung (also 2 Tabellen) zwischen deinem "Objekt" (also dessen Tabelle) und der Tabelle der variablen Liste.

edit: oder du benutzt einen OR-Mapper, der dir das Datenbankschema automatisch generieren kann.

Komm bloß nicht auf die Idee, die Liste mit irgendwelchen Sonderzeichen zu 'imploden' und einfach als String einzutragen (das ist möglich, aber das widerspricht dem Grundsatz der relationalen Datenbank!).

Der 'korrekte' Weg ist die 1:N Beziehung, wie oben bereits gesagt. Die (finde ich) bessere Alternative ist: Keine Relationale Datenbank, sondern eher sowas wie MongoDB. Das ist zwar eine Umstellung, aber macht dann auch vieles einfacher und schneller

benneque schrieb:

...sondern eher sowas wie MongoDB. Das ist zwar eine Umstellung, aber macht dann auch vieles einfacher und schneller

Zum Vergrößern anklicken....

Und vieles komplizierter, vor allem für Neulinge. Stichwort ACID. SQL passt schon für's erste, später kann man dann sicherlich NoSQL-DBs anschauen.

benneque schrieb:

Komm bloß nicht auf die Idee, die Liste mit irgendwelchen Sonderzeichen zu 'imploden' und einfach als String einzutragen (das ist möglich, aber das widerspricht dem Grundsatz der relationalen Datenbank!).

Zum Vergrößern anklicken....

Ich muss ehrlich zu geben, dass war mein erster Gedanke ^^
Allerdings dachte ich mir schon, dass das nicht das gelbe vom Ei ist bzw. es auch besser gehen muss, deshalb auch der Thread hier.

Danke auf jeden Fall schon mal für die schnellen Antworten, ich werde mal ein bisschen zum Thema 1:N Beziehungen googlen und mich schlau machen.

Gruß

Soooo wichtig ist ACID auch wieder nicht. Sieht man wohl am Besten daran, dass MySQL es bis vor kurzem nicht per default unterstützt hat (erst seit InnoDB Standard ist) und trotzdem seit vielen Jahren im Großeinsatz ist!
Und MongoDB unterstützt ein paar Kleinigkeiten von ACID nicht, wie multi-collection-transactions. Und wenn man es doch nutzen will, muss man sich eben das 'workaround-pattern' einprägen.

Aber das ist alles gar nicht so wichtig. Viel viel viel wichtiger finde ich, dass ich es schade finde, dass so weniger nicht-SQL Datenbanken benutzt werden. Vielleicht sollte man das Internet von seinen Anfängen säubern (PHP + MySQL). Damit ich mich in 'modernen' Projekten an der Uni nicht mehr mit so einem Dreck rumschlagen muss

Das soll nur heißen: Es gibt inzwischen Datenbanken die in jeder Hinsicht schneller als alle SQL-Datenbanken sind, also für jeden Datentyp und jede Relation! Klar sind Tabellen schön für's menschliche Auge und einfacher zu verstehen als n-Dimensionale Graphen, aber damit beschäftigt sich ja eh keiner weil es Query-Languages gibt, mit denen man quasi jede Datenbank extrem einfach füllen und auslesen kann


EDIT: Das mit 1:N ist eigentlich ganz einfach.
Du hast meinetwegen ein Objekt X. X hat die ID 42 und dann eine Liste von Strings "a","b","c". Dann gibt's noch Objekt Y mit der ID 23 und der Liste "x","y","z".

Jetzt hast du Tabelle 1 für die Objekte (ich hab noch das optionale Attribut 'Objektname' hinzugefügt, das hat aber nichts mit den Listen zu tun):

Und Tabelle 2 mit den Listen selbst:

Dann machst du einfach eine Abfrage, die für das jeweilige Objekt zusätzlich in der Tabelle 2 nachschaut, welche Einträge für die Liste vorhanden sind.

Bei der Erstellung der Tabellen setzt man dann normalerweise noch einen Foreign Key, damit z.B. automatisch alle Listen-Elemente gelösche werden ,wenn man das Objekt löscht.

Für den Einstieg über SQL mit 1:n.

Später NHibernate, die beste Framework für sowas.

Da haben wir zwei Ansichten und werden uns vermutlich nicht einig hier, aber für mich ist Transaktionssicherheit so ziemlich das wichtigste an einer Datenbank. Nicht falsch verstehen, finde die momentane NoSQL-Welle mit ihrem Speed und ohne Impedance mismatch zwischen oop und Datenbank auch genial, aber ich glaube nicht, dass es das ist, was man dem TS an dieser Stelle vorschlagen sollte

PS: multi collection transactions finde ich nicht gerade eine Kleinigkeit. Das mit MySQL stimmt (wobei es sicherlich seit Anfang des Jahrtausends möglich ist), allerdings braucht man sich auch nicht wundern, warum im professionellen Umfeld eher Oracle und MS SQL zu finden sind.

@Thaxll'ssillyia: Das ist vielleicht schön zur Abstraktion, aber insgesamt ziemlich sinnfrei...
Wenn man Hibernate (oder NHibernate) benutzt, kann man auch gleich zu NoSQL greifen. Die Art WIE man dann seine Objekte speichert und abruft ist völlig identisch (die Befehle heißen vielleicht ein wenig anders). In beiden Fällen sagt man einfach 'Hol mir das Objekt mit ID 12' oder 'Speicher dieses Objekt'. Nicht mehr, nicht weniger. Der einzige Unterschied ist, dass man sich halt mit einer NoSQL DB anfreunden müsste (ist nicht sonderlich schwer), aber dafür ist man endlich weg von SQL, hat keinen Wrapper zwischen Objekt und Datenbank und kann sich freuen eine moderne Technologie kennengelernt zu haben

@carom: Ich versteh dich wirklich. Ich habe lang genug mit SQL gearbeitet (Postgres und MySQL) und inzwischen schon viel dazu gelernt. Klar ist das System gut und extrem ausgereift, aber in Zeiten von OOP will ich meine Objekte einfach nicht mehr auseinanderpfücken
Und nach den vielen vielen Vorleseungen, praktischen Erfahrungen, etc. mit relationalen Datenbanken weiß ich, dass man in den meisten Fällen (vor allem in der WebProgrammierung) auf ACID verzichten kann und eine Datenbank temporär inkonsistent sein kann, ohne dass es den Benutzer irgendwie stört Es gibt halt wirklich sehr viele Szenarien, wo man Datensätze hat, die immer nur von genau einem Benutzer manipuliert werden können (nehmen wir mal z.B. den Warenkorb in einem Onlineshop).
Aber klar, es gibt genügend andere Szenarien, wo man sichere Transaktionen braucht! Gar keine Frage! (Man kann auch prima MongoDB und MySQL zusammen benutzen, um beides zu haben Performance und Sicherheit. Man muss halt nur genau wissen, welche Teilprogramme nicht auf sichere Transaktionen angewiesen sind )

Ich schlage immer SQL/mySQL vor, weil es in der Industrie und Wirtschaft benutzt wird (bei uns in der Firma wird es auch verwendet). Es ist einfach zu verstehen, stabil und es gibt ne Menge Frameworks/Tutorials dazu. Wozu dann für so eine komplizierte Lösung für einen Einsteiger?

Lasst ihn doch erstmal mit mySQL 2 Tabellen (eine mit strings und eine mit der Auflistung) erstellen und das Prinzip kennenlernen.

Du hast mich, glaube ich, missverstanden. Ich wollte nicht vom Einstieg mit rohem SQL abraten, sondern nur aufzeigen, dass Hibernate genau gleich einfach/schwer zu benutzen ist wie NoSQL. Hibernate macht ja genau das: Einen Wrapper bereitstellen, mit dem man Objekte einfach speichern und abrufen kann Der einzige Unterschied ist halt, dass man eine NoSQL Datenbank aufsetzen muss, was mit 'nem guten Tutorial auch nur 15 Minuten dauert.

@benneque

Danke für die Erklärung, so präzise war auf Anhieb nichts zu finden ^^

Nur, dass ich es richtig verstanden habe, hier nochmal ein konkretes Beispiel:
In meinem Fall sind die Objekte ausgewertete Alarmfaxe für die Feuerwehr.
Da gibt es dann Beispielsweise Eigenschaften wie Stichwort, Meldebild, Straße, etc..
Am Ende steht dann eine Liste mit den alarmierten Einsatzmitteln also z.b. Wärmebildkamera, Löschwasser, etc...

Diese Liste variiert natürlich bei jedem Einsatz in ihrer Länge, je nachdem was alles benötigt wird.
Es würde also so aussehen:

Tabelle 1

Tabelle 2

So müsste das dann aussehen oder?

Ja, das sieht gut aus. Nur in der zweiten Tabelle dürfte es keine ID 3 geben Weil die in Tabelle 1 nicht vorhanden ist Aber das nur am Rande.

Man könnte das Schema wahrscheinlich noch optimieren. So wie es aussieht gibt es eine relativ feste Menge an Einsatzmitteln oder? Dann könnte man es z.B. so machen:




Damit eliminiert man Redundanzen (also mehrfache Vorkommen von identischen Einträgen). Tabelle DREI dient einfach nur dazu, um Tabelle EINS und Tabelle ZWEI zu verknüpfen. Das macht für die Abfrage minimal komplizierter (aber es gehört zum guten Ton unter DB Designern )...
Das macht man aber wirklich nur(!), wenn die Eintrage aus Tabelle ZWEI immer wieder benutzt werden.

benneque schrieb:

Ja, das sieht gut aus. Nur in der zweiten Tabelle dürfte es keine ID 3 geben Weil die in Tabelle 1 nicht vorhanden ist Aber das nur am Rande.

Zum Vergrößern anklicken....

Oh ja stimmt, da war die tippende Hand schneller als das denkende Hirn ^^
Dachte eigentlich ich hätte die 3 auch oben mit ... eingefügt.

Ich werde es denke ich über die erste Variante lösen, das ist für mich vorerst am einfachsten.

Vielen Dank für Deine Hilfe

Keine Ursache

Ja, die Varianten erfüllen beide Ihren zweck. Die zweite Variante hätte noch den Vorteil, dass man die vorhandenen Einsatzmittel schon im Programm auflisten könnte und dann per Checkbox anwählt
Dazu dann noch ein Feld, wo man ein neues Einsatzmittel eintragen kann, falls es etwas noch nicht gibt. Aber die Abfrage zum Auslesen und die zum Eintragen wird halt komplexer.

Kannst du dir ja als nächsten Schritt zum SQL lernen notieren



EDIT: für den Rest vielleicht noch interessant: http://couchdb.apache.org/docs/overview.html
CouchDB ist NoSQL und hat ACID!