DB-Abfrage für viele, gleichartige Spalten

[HaZweiOh]

Hallo,

ich habe zwei DB-Tabellen, die ich hier vereinfacht darstelle. Thematisch dürfte Euch der Inhalt bekannt vorkommen

Tabelle Anschluss:

ID	Bezeichnung
4081	USB 3.0 (Typ A)
4523	DisplayPort 1.4

Tabelle Mainboard:

Port1_Anzahl	Port1_Typ	Port2_Anzahl	Port2_Typ	....
4	4081	1	4523

Die Tabelle Mainboard hat viele Felder, die jeweils eine Anschluss-ID beinhalten. Nun möchte ich eine "lesbare" View erstellen, die zu jeder ID die Bezeichnung ausgibt. Also quasi "4x USB 3.0 und 1x DisplayPort". Da es um viele Anschlüsse geht, kann ich keinen Join auf ein bestimmtes Feld von Mainboard machen. Und ich kann die Anschlüsse nicht in einer Enumeration als Sammelbecken versenken, weil es zu jedem Anschluss Zusatzinformationen gibt, die in einem anderen Feld (Port 1 Anzahl) oder in der Spaltenüberschrift (Grafik1 = 4523) stehen.

Wie frage ich das am besten ab?

 

[Anteru]

Eine Subquery sollte das machen können. Einfach für den Port-Type eine Subquery mit der ID auf die Anschluss-Tabelle.

 

[HaZweiOh]

Hmm, dann wären es einerseits 10 Subqueries, und andererseits möchte ich mir am liebsten die ganze Tabelle Mainboard (also alle Zeilen) in "lesbar" ausgeben lassen. Gibt es keine Abkürzung dafür? Das nachzuschlagende Feld ist ja immer eine Anschluss-ID ist, zu der immer die Bezeichnung gesucht wird.

 

[Anteru]

Entweder Subqueries oder ein Join pro Spalte, ich sehe da jetzt nicht viele Alternativen. Die "richtige" Lösung wäre die Anschlüsse nicht als Spalten pro Mainboard zu speichern, sondern eine Tabelle haben die die Zuordnung macht, also sowas wie "Mainboard_Anschlüsse" und das hätte als Spalten MainboardID, AnschlussID, Anzahl. Dann geht das wieder sehr schön mit einem einzigen Join.

Ein View mit Subqueries erzeugt die Tabelle "Mainboard" in lesbar. Die Anforderung wäre also erfüllt

Die 10 Subqueries sollten ja jetzt nicht so wild sein. Ein EXPLAIN sollte da 10 Zugriffe via Index zeigen. Das ganze mit einer Query zu erschlagen kann ja so oder so nicht gehen, weil Du ja potentiell 10 verschiedene Ergebnisse braucht, also irgendwo werden 10 Queries passieren müssen ...

 

[RalphS]

Wenn man auf Ideen wie Port<no>Typ kommt, macht man meiste schon was falsch.

Wie angedeutet: Tabellen aufmachen, die sachlich getrennt sind, und dann Joins drüber plus View für die Ansicht.

Also eine Tabelle Konnektoren, eine Tabelle für Formate, eine für Verbindungssysteme (pcie, agp,Isa,...) und was es halt noch so Erfassenswertes gibt.

Das Mainboard ist dann nur noch eine Hülltabelle drumrum. Sagen wir es gibt sowas wie MB.format =0 (itx). Für facettierte Komponenten (USB) nochmal eins drüber, zB MbUsb.MbId=18(also exakt DAS MB), UsbId=5(usb 1.1 intern, in eigener Tabelle aufgeschlüsselt), count= 4 (so viele gibt es).

Bitte nie vergessen: Dbms sind NICHT Excel.

 

[HaZweiOh]

Hmm, ich bin für Änderungen an der DB-Struktur durchaus offen, allerdings muss man auch bedenken, dass die Datenbank ein Hobby-Projekt ist, wofür ich keine Eingabeformulare habe. Vermutlich wird es auch nie welche geben, weil ich die bei jeder DB-Änderung wieder anpassen müsste. Ich gebe also direkt in phpMyAdmin ein.

Die Universal-Tabelle Anschluss hat den großen Vorteil, dass alles sehr leicht zu pflegen ist. Jede Hardware hat diverse Anschlüsse: das Mainboard, die Grafikkarte, die externe Festplatte. Eine neue Tabelle Mainboard-Anschlüsse wäre noch in Ordnung, aber wenn ich das alles in zig Zusatztabellen aufschlüssele, würde es so kompliziert, dass es praktisch kaum noch bedienbar ist. Für eine (hier nicht vorliegende!) berufliche Nutzung würde man das natürlich anders machen. Dann hätte man aber auch die Zeit, mehrere Mannmonate in das Design und die Programmierung zu stecken.

 

[Oelepoeto]

Klingt für mich nach ein Fall für die Pivotierung, wobei ich mir deine Datenstruktur gerade nicht so veranschaulichen kann (bin etwas rostig DB-mäßig)

 

[parats]

Wenn man auf Ideen wie Port<no>Typ kommt, macht man meiste schon was falsch.

Wie angedeutet: Tabellen aufmachen, die sachlich getrennt sind, und dann Joins drüber plus View für die Ansicht.

Also eine Tabelle Konnektoren, eine Tabelle für Formate, eine für Verbindungssysteme (pcie, agp,Isa,...) und was es halt noch so Erfassenswertes gibt.

Das Mainboard ist dann nur noch eine Hülltabelle drumrum. Sagen wir es gibt sowas wie MB.format =0 (itx). Für facettierte Komponenten (USB) nochmal eins drüber, zB MbUsb.MbId=18(also exakt DAS MB), UsbId=5(usb 1.1 intern, in eigener Tabelle aufgeschlüsselt), count= 4 (so viele gibt es).

Bitte nie vergessen: Dbms sind NICHT Excel.

Kann man so nur unterschreiben und als Gedankenstütze vielleicht noch der Zusatz, dass Du dir erstmal ein Datenmodell aufmalen solltest, dass alles so darstellt wie Du es später abfragst und zwar ohne lästiges kaskadieren. Auch wenn es nur ein Hobby ist, sollte man lieber einige Stunden in die Modellierung investieren als nach viel Arbeit zu merken, dass das Datenmodell zuviele Ecken und Kanten hat.

 

[HaZweiOh]

Okay, ich schaue mir die Struktur nochmal an. Das Ziel ist wie gesagt (gleichermaßen) eine einfache Abfrage und eine schnelle Eingabe hinzukriegen.