[MySQL] SELECT lösung gesucht bei einer mehrspaltingen Verknüpfungstabelle

[strolch00]

Hallo

Spricht etwas dagegen mehrspaltige Verknüpfungstabellen zu verwenden?

Ich habe eine Tabelle team_link
in der sind folgende Spalten
link_id|team_id|de_id|dbms_id|lang_id
1|1|NULL|1|1
2|1|NULL|NULL|19
3|1|NULL|NULL|22
4|1|NULL|1|2
5|1|NULL|NULL|43
6|1|NULL|3|1

Jede *_id steht für eine andere Tabelle wo die Daten jeweiligen Daten eingetragen sind. dbms_id steht für Datenbanksystem und lang_id für Scriptsprache.

Meine Ausgabe die ich haben will umschreibe ich mal mit den Tabellen Spalten:
1.lang_id/1.dbms_id[/2.dbms_id][/...][, 2.lang_id/1.dbms_id[/2.dbms_id]

die spätere fertige Ausgabe würde dann so aussehen:
PHP/MySQL/InnoDB, CGI/MySQL, JAVA, Pascal, Visual Basic

Ich habe schon unzählige Query versucht und sämtliche Stringfunktionen im Manual durchstöbert aber ich finde einfach nicht den richtigen Abfragesyntax.

mein aktueller Query lautet so:

SELECT
CONCAT_WS('#', CONCAT_WS('/', l_one.`lang_id`, l_one.`dbms_id`), l_two.`lang_id`) as `spezial`
FROM `team_link` as l_one
JOIN `team_link` as l_two
ON (l_one.`team_id` = l_two.`team_id` AND l_two.`dbms_id` IS NULL)
WHERE l_one.`team_id` = 1
GROUP BY l_one.`team_id`, l_two.`lang_id`

Jetzt die Frage habe ich einen Hänger und es geht so in der Art oder Funktioniert es so nicht? Google will leider auch nix zum Thema ausspucken ich habe immer nur Verknüpfungsbeispiele mit zweispalten gefunden. Ist dies vielleicht besser?

Hoffe hier kann mir jemand helfen.

 

[ice-breaker]

müssen die Daten alle zwangsläufig in der 3. Normalform liegen?
Weil als Datentyp Set für die Programmiersprache würde einiges weniger Arbeit für MySQL bedeuten.

Leider konnte ich auch nicht genau verstehen, was du machen willst. Könntest du vllt aus allen beteiligten Tabellen mal 2-3 Beispieldatensätze posten und dann mal schreiben, was dein Query genau tun soll? Also was nun als Ergebnis einer Abfrage herauskommen soll, habe das nicht so ganz verstanden.

 

[strolch00]

Naja welche Datentyp ist mir eigentlich egal ich dachte nur das man es so besser auslesen kann und man hat weniger Speicherverbrauch.

Hier die Tabellen sind nicht besonderes:
team_lang Tabelle:

lang_id | description
1         |php
2         |CGI
3         |JAVA

team_dbms Tabelle

dbms_id | descrition
1          | MySQL
2          | InnoDB
3          | SQLite

team_link Tabelle

link_id | team_id | des_id | dbms_id | lang_id
1        | 1         |    NULL |     1     |     1
2        | 1         |   NULL  |    NULL |     3
3        | 1         |   NULL  |    2      |     1
4        |  1        |   NULL  |    1      |     2
5        |  2        |    NULL |    1      |     1
6        |  2        |   NULL  |    NULL |     3
7        |  3        |NULL     |    NULL |    1
8        |  3        |  NULL   |    2      |    2

Und die Ausgabe soll so aussehen

Teammember Nr 1:
kann: PHP/MySQL, JAVA, CGI/MySQL
Teammember Nr 2:
kann: PHP/MySQL
Teammember Nr 3:
kann: PHP, CGI/InnoDB

Hoffe du weist wie ich es nun meine. Set als Datentyp kam mir da jetzt eigenlich nicht in den Sinn zumal es sehr Speicherintensiv sein soll und schwer updatebar, aber ich hab mein Wissen in der hinsicht auch net weiter vertieft.

Fals du Dich im Query über das '#' als Trenner wunderst das ist mein explode zeichen dort explode ich immer und baue in einer foreach schleife die Ansicht als liste zusammen.
Die ansicht soll halt verdeutlichen welches Teammitglied was kann, Nr.: 1 kann php mit mysql anbindung, Nr.: 3 hingegen NUR PHP aber er kann CGI mit MySql anbindung.

*edit die spalte des_id ist für Designer was di alles können dort ist es aber einfach das ist einfach nur auslesen die hamm ja nur webdesign, ava, banner, usw.

 

[ice-breaker]

neija eine Set-Spalte kann mehere vordefinierte Werte speichern, und nutzt intern einer 2er Bit-Komplement, von daher ist die Speicherung sehr effizent. Und auslesen und Eintragen sind nicht wirklich schwer, schlag einfach mal im MySQL-Manual nach

Natürlich wiederspricht es aber der 3. Normalform !!!

 

[strolch00]

Jop ok werde ich mal tun aber so wie es jetzt ist siehst du keine Lösung?

*edit
Und wenn nicht kannst du mir ein beispiel nenne wie ich das set deiner Meinung nach wo definieren soll? Ich sehe einfach nicht wie mir dieser Datentyp helfen könnte.

 

[sto]

Ich halte deinen Ansatz für falsch, die Ausgabe in einer Zeile in SQL erledigen zu wollen.
Das ist mit einem relationalen Datenbankmodell schlecht zu vereinbaren.
Dein Tabellenmodell kann dich eigentlich auch nur in die Sackgasse führen, weil es nicht den Regeln eines relationalen Datenbankmodells folgt.

Ich würde die Tabellen team_lang und team_dbms zusammenlegen, weil die zu speichernden Informationen nicht so unterschiedlich sind, dass mehrere Tabellen gerechtfertigt sind.
Die Tabelle könnte man team_skills oder ähnlich nennen. Ein Teammitglied verfügt über 0 bis n Fähigkeiten. Ob dies PHP, MySQL oder "Schnürsenkel zubinden" ist, ist ja gleichgültig.

Dann hast Du nur noch zwei Tabellen und dann darauf einen normalen Join zur Abfrage (in Tabelle team_link dann nur noch drei Felder, id, member_id, skill_id)
Die Abfrage erweitert sich natürlich, wenn Du noch vom Teammitglied den Namen aus eine anderen Tabelle ausliest

Die formatierte Ausgabe, wie von Dir beschrieben, sollte dann m.E. von einer Programmiersprache nach der Abfrage übernommen werden.

 

[ice-breaker]

*edit
Und wenn nicht kannst du mir ein beispiel nenne wie ich das set deiner Meinung nach wo definieren soll? Ich sehe einfach nicht wie mir dieser Datentyp helfen könnte.

SET('PHP','Java','Delphi') etc.

sto, was du beschreibst ist wieder Denormalisierung der Datenbank, aber wenn er den Weg durch SET sowieso geht ist der Weg mit SET eindeutig einfacherer

 

[strolch00]

Ich habe es hauptsächlich so kompliziert gemacht weil ich ja sagen wollte
er kann php/mysql/InnoDB, cgi/InnoDB, Visual Basic, AJAX

Wenn die Spalte der DBSprache MIT der jeweiligen Scriptsprache net gegeben wäre kann er die halt nicht.

So kann ich jetzt nur alles ausgeben

PHP, MySQL, CGI, InnoDB, AJAX

das ist halt das was mir net so gefällt. Weil wenn ich PHP kann und MySQL in PHP muss ich es nochlange nicht in CGI können.

 

[sto]

SET('PHP','Java','Delphi') etc.

sto, was du beschreibst ist wieder Denormalisierung der Datenbank, aber wenn er den Weg durch SET sowieso geht ist der Weg mit SET eindeutig einfacherer

Die Tabelle team_link ist m.E. totaler Murks und kann eigentlich nur Schwierigkeiten machen.

Aber wenn man sowieso auf die Theorie pfeift, warum dann nicht einfach ein Textfeld. Dann schreibt man die Informationen dort einfach so rein, wie einem das passt. Ein einfacher Select auf das Feld reicht dann ja auch.

 

[ice-breaker]

Aber wenn man sowieso auf die Theorie pfeift, warum dann nicht einfach ein Textfeld. Dann schreibt man die Informationen dort einfach so rein, wie einem das passt. Ein einfacher Select auf das Feld reicht dann ja auch.

weil ein textfeld (varchar) die tabelle von starr zu dynamisch umwandeln würde, was geschwindigkeit kostet und für die Datenbank ein Set-Feld weit effizenter als ein CSV feld mit den angaben ist !