Array of Integer in MySql

[DelTurbo]

Hi,
geht das überhaupt? Ich habe mehrere IDs von Datensätzen die einem User zugeordnet sind. Im moment habe ich das als String mit , getrennt in der Datenbank.

Nun dachte ich, wenn man das als Interger Array in die MySql bekommt, ist das bestimmt eleganter und man könnte dann auch in diesem Array suchen ob eine ID enthalten ist.

Allerdings google ich schon seit einiger zeit, und find nix gescheites.

Nun zu den Fragen.
Geht das überhaupt was ich vorhabe?
Wenn ja, wie legt man das Array an? CREATE TABLE test (??)?
Wie frage ich ab, ob in diesem Array z.b. der wert 10 enthalten ist? SELECT * FROM test WHERE Feld=??????
Wie lese ich das Array ein? Weil ein FieldByName('Feld').AsArray gibt es ja nicht.

Vielen dank im voraus

[Der schöne Günther]

Ich verstehe nicht (wie immer).

Das läuft doch dem Konzept einer relationalen DB vollkommen zuwider. Du hast doch eine 1:n-Kardinalität von User: Datensätze. Dann braucht deine Datensätze-Tabelle doch nur einen Fremdschlüssel auf den Primärschlüssel deiner User-Tabelle.

Hast du weitere Einschränkungen, wie dass zu jedem Nutzer mindestens ein Datensatz existieren muss?

Aber entweder stehe ich auf dem Schlauch, oder das mit Arrays und dann versuchen irgendwie zu parsen ist ein wirklich ungünstiger Ansatz.

[DelTurbo]

Hmmm, also mal ein beispiel.

Ich habe 10.000 Artikel und 20 Hauptgruppen. Jeder Artikel kann mehr als eine der vorhanden Hauptgruppen zugehören.

z.b.
Artikel 1 gehöhrt zu gruppe 1,7,12,19
Artikel 2 gehöhrt zu gruppe 1,2

Diese zugehörigkeit steht natürlich im Artikel drin. Im moment wie gesagt als String mit Komma getrennt.

Mir ist keine SQL-Abfrage bekannt, wo ich nun sagen kann, zeige mir alle Artikel die in gruppe 3 sind.

[baumina]

Deine Tabellen sollten in diesem Fall folgendermaßen angelegt werden:

1. Tabelle Artikel (ArtID, ...)
2. Tabelle Hauptgruppen (GrpID, Gurppenname, ...)
3. Tabelle Zuordnung ArtGrp (ZuOrdID, ArtID, GrpID)

[DeddyH]

n:m-Beziehung

[DelTurbo]

Zitat:

Zitat von baumina (Beitrag 1246752)

Deine Tabellen sollten in diesem Fall folgendermaßen angelegt werden:

1. Tabelle Artikel (ArtID, ...)
2. Tabelle Hauptgruppen (GrpID, Gurppenname, ...)
3. Tabelle Zuordnung ArtGrp (ZuOrdID, ArtID, GrpID)

Die 3. Tabelle wollte ich mir einfach sparen. Hätte ja auch geklappt wenn man ein Feld als Array of Integer hätte. Aber anscheinden komme ich laut euch beiden nicht um die 3. Tabelle drumherum. Schade eigentlich.

Trotzdem vielen dank für eure Hilfe.

[Sherlock]

http://de.wikipedia.org/wiki/Normali...form_.281NF.29

Das mit der Normalisierung ist in der Praxis immer wieder mal ein heikles Thema, aber die erste Normalform sollte bitte immer drin sein.

Sherlock

[Jumpy]

Zitat:

Zitat von DelTurbo (Beitrag 1246750)

Hmmm, also mal ein beispiel.

Ich habe 10.000 Artikel und 20 Hauptgruppen. Jeder Artikel kann mehr als eine der vorhanden Hauptgruppen zugehören.

z.b.
Artikel 1 gehöhrt zu gruppe 1,7,12,19
Artikel 2 gehöhrt zu gruppe 1,2

Diese zugehörigkeit steht natürlich im Artikel drin. Im moment wie gesagt als String mit Komma getrennt.

Mir ist keine SQL-Abfrage bekannt, wo ich nun sagen kann, zeige mir alle Artikel die in gruppe 3 sind.

Das ist natürlich nur die Fortführung des Mumpitzes, aber das ginge via

...
where gruppe like '%,3,%' or gruppe like '3,%' or gruppe like '%,3' or gruppe='3'

[gravedigger]

Um es noch weiter zu treiben geht auch ein

...
where find_in_set(id, gruppe)


Gruß aus den sonnigen Dortmund

Frank Graeber

[Sherlock]

Klartext: Das geht, und es wurden ja schon Vorschläge gebracht, aber da sich Deine Fragestellung doch sehr noch nach "Planung" oder "früher Entwicklung" anhört:
MACH DAS BITTE NICHT!
Du bringst Dich dadurch unnötig in Teufels :evil: Küche. Nur weil etwas geht, macht man es ja trotzdem nicht. Immerhin verwendest Du ja MySQL und nicht eine Textdatei zum speichern Deiner Daten, und das wäre auch möglich.

Normalisier Deine Tabellen soweit es geht. Dritte Normalform sollte noch drin sein, die erste ist IMHO Pflicht.

Sherlock

[DelTurbo]

Keine angst. Ich habe oben ja schon geschrieben das ich das über die 3. Tabelle machen werde.

Trotzdem finde ich es Interessant was doch so alles geht :wink:

[DeddyH]

Vorsicht: zum Teil sind die Vorschläge MySQL-spezifisch, wenn Du das verwendest und später mal das DBMS wechseln möchtest, viel Spaß.

[gravedigger]

Das sollte jetzt vielleicht nicht in eine Diskussion über die Vor- und Nachteile der verschiedenen DBMS enden.
Aber normalerweise überlegt man sich doch vorher welche Datenbank man verwendet.

In der Regel hat es doch lizenztechnische und/oder monetäre Gründe.

Da der Zugriff auf die Datenbank über MyDac erfolgt, kann man davon ausgehen das MySQL die Datenbank seiner Wahl ist.
Somit kann er und sollte er auch die MySQL-spezifischen Funktionen benutzen um für MySQL das beste Ergebnis zu bekommen.
Wer wechselt schon ständig sein DBMS?

Natürlich ist der Weg über eine dritte Tabelle mit n:m-Beziehung der bessere Weg.
Aber auch auf diesem Weg kann man evtl. mit

... where find_in_set(id, gruppe)

zum Ziel kommen.


Gruß aus Kamen

Frank Graeber

[DeddyH]

Was ich meinte: es ist ja schon vereinzelt vorgekommen, dass Kunden nach Unterstützung anderer DBMS fragen. Das erfordert meist sowieso schon einigen Aufwand, je nachdem, wie systemgebunden man das Ganze aufgebaut hat. Da tut es IMO nicht Not, von vornherein Designfehler zu ignorieren, nur weil das derzeit verwendete DBMS Funktionalitäten bereitstellt, die diese Fehler übertünchen.