22
Mehrfache JOIN-Verknüpfung
Hallo liebe Forumsgemeinde,
bin seit längerem als passiver Nutzer auf dieser Seite und habe nun ein Problem, das nicht so einfach zu sein scheint.
Ich habe fünf Tabellen, diese sollen in eine große Tabelle verknüpft werden. Habe mir bereits Tutorials und mir auf mysql.com die Syntax angeschaut.
Zwei Tabellen zusammenzufassen stellt kein Problem dar, jedoch ab der dritten Tabelle fängt das Dilema an.
SELECT dev_produkte.prdNr, eingabe_allgemein.allgemein_parameter
FROM dev_produkte INNER JOIN (eingabe_allgemein LEFT JOIN eingabe_alle ON eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id)
ON dev_produkte.id = eingabe_alle.prdid
Wenn ich den Code jedoch erweitere und zwar so:
SELECT dev_produkte.prdNr, eingabe_allgemein.allgemein_parameter, eingabe_dc.dc_parameter
FROM dev_produkte
INNER JOIN (eingabe_allgemein, eingabe_dc
LEFT JOIN eingabe_alle ON eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id
AND eingabe_dc.id = eingabe_alle.eingabe_dc_id)
ON dev_produkte.id = eingabe_alle.prdid
erhalte ich folgende Fehlermeldung:
#1054 - Unknown column 'eingabe_allgemein.id' in 'on clause'
Hat einer einen rat, wie ich mehrere JOINs verschateln kann?
Zur besseren Vorstellung der Verknüpfung hier mal ein Screenshot:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Gruß, Luke.
bin seit längerem als passiver Nutzer auf dieser Seite und habe nun ein Problem, das nicht so einfach zu sein scheint.
Ich habe fünf Tabellen, diese sollen in eine große Tabelle verknüpft werden. Habe mir bereits Tutorials und mir auf mysql.com die Syntax angeschaut.
Zwei Tabellen zusammenzufassen stellt kein Problem dar, jedoch ab der dritten Tabelle fängt das Dilema an.
SELECT dev_produkte.prdNr, eingabe_allgemein.allgemein_parameter
FROM dev_produkte INNER JOIN (eingabe_allgemein LEFT JOIN eingabe_alle ON eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id)
ON dev_produkte.id = eingabe_alle.prdid
Wenn ich den Code jedoch erweitere und zwar so:
SELECT dev_produkte.prdNr, eingabe_allgemein.allgemein_parameter, eingabe_dc.dc_parameter
FROM dev_produkte
INNER JOIN (eingabe_allgemein, eingabe_dc
LEFT JOIN eingabe_alle ON eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id
AND eingabe_dc.id = eingabe_alle.eingabe_dc_id)
ON dev_produkte.id = eingabe_alle.prdid
erhalte ich folgende Fehlermeldung:
#1054 - Unknown column 'eingabe_allgemein.id' in 'on clause'
Hat einer einen rat, wie ich mehrere JOINs verschateln kann?
Zur besseren Vorstellung der Verknüpfung hier mal ein Screenshot:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Gruß, Luke.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 77018
Url: https://administrator.de/forum/mehrfache-join-verknuepfung-77018.html
Ausgedruckt am: 22.02.2025 um 08:02 Uhr
22 Kommentare
Neuester Kommentar
Moin LuckyLuke,
willkomen im Forum.
Wenn Du tatsächlich alle Tabellen über LEFT JOINs verbinden willst (sprich: die Detail-Werte in eingabe_xxx könnten fehlen, auch wenn ein dev_produkte-Datensatz vorhanden ist), dann so:
Du kannst NICHT einen INNER Join auf DateiA und DateiB mit dieser Syntax machen:
Sondern immer beim JOINen immer nur zwei Tabellen miteinander verbinden.
Aber diese "Tabellen" dürfen auch wieder Ergebnis eines Joins sein.
Grüße
Biber
willkomen im Forum.
Wenn Du tatsächlich alle Tabellen über LEFT JOINs verbinden willst (sprich: die Detail-Werte in eingabe_xxx könnten fehlen, auch wenn ein dev_produkte-Datensatz vorhanden ist), dann so:
SELECT dev.prdNr, eingabe_allgemein.allgemein_parameter
FROM dev_produkte dev
INNER JOIN (
eingabe_allgemein LEFT JOIN eingabe_alle ON eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id
LEFT JOIN eingabe_dc ON eingabe_dc.id = eingabe_alle.eingabe_dc_id
LEFT JOIN eingabe_xy ON eingabe_xy.id = eingabe_alle.eingabe_xy_id
[...usw...]
)
ON dev.id = eingabe_alle.prdid
Du kannst NICHT einen INNER Join auf DateiA und DateiB mit dieser Syntax machen:
...INNER JOIN (eingabe_allgemein, eingabe_dc .....)
Sondern immer beim JOINen immer nur zwei Tabellen miteinander verbinden.
Aber diese "Tabellen" dürfen auch wieder Ergebnis eines Joins sein.
Grüße
Biber
Versuch mal die ON statements seperat zu klammern.
SELECT dev_produkte.prdNr, eingabe_allgemein.allgemein_parameter, eingabe_dc.dc_parameter FROM dev_produkte INNER JOIN (
eingabe_allgemein, eingabe_dc LEFT JOIN
eingabe_alle ON (eingabe_allgemein.id = eingabe_alle.eingabe_allgemein_id
AND eingabe_dc.id = eingabe_alle.eingabe_dc_id)
)
ON ( dev_produkte.id = eingabe_alle.prdid )
Hey Biber, danke für deine prompte Antwort. Diese hat mir etwas weitergeholfen.
Ich verstehe nicht so ganz richtig, was du mit dem JOINEN von nur zwei Tabellen meinst und diese wiederrum erneut joinen?
Ich habe deinen Vorschlag mal angewandt und erhielt nur für die erste Spalte "eingabe_allgemein" die Ausgabe, siehe hier:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Gut das liegt sicherlich an dem INNER JOIN, da er nur die ersten 4 Zeilen aus "eingabe_allgemein" sieht. Wende ich für die anderen den INNER JOIN an sind alle Felder NULL...
Nebenanmerkung: Diese Tabelle ist dazu da, damit die verwaltung später leichter fällt und alles auf einem Fleck sichtbar ist. Fahre ich mit dieser Idee richtig oder gibt es bessere Alternativen?
Ich verstehe nicht so ganz richtig, was du mit dem JOINEN von nur zwei Tabellen meinst und diese wiederrum erneut joinen?
Ich habe deinen Vorschlag mal angewandt und erhielt nur für die erste Spalte "eingabe_allgemein" die Ausgabe, siehe hier:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Gut das liegt sicherlich an dem INNER JOIN, da er nur die ersten 4 Zeilen aus "eingabe_allgemein" sieht. Wende ich für die anderen den INNER JOIN an sind alle Felder NULL...
Nebenanmerkung: Diese Tabelle ist dazu da, damit die verwaltung später leichter fällt und alles auf einem Fleck sichtbar ist. Fahre ich mit dieser Idee richtig oder gibt es bessere Alternativen?
Moin LuckyLuke,
also: grundsätzlich bin ich schon relativ sicher, dass die von mir skizzierte Syntax formal richtig ist.
Was die Sinnhaftigkeit/Notwendigkeit Deiner SEHR ausgeprägten Zerfaserung der Detailwerte angeht... das ließe sich eher beurteilen, wenn die Tabellen mal auf dem Tisch lägen.
Wenn die alle eine total unterschiedliche Struktur haben (sollten), dann besteht ein gewisser Zwang zu einer Tabelle für "eingabe_dc-Parameter" und einer Tabelle für "eingabe_Antennen-parameter" etc. etc.. Und dann leider auch der Druck zu einer künstlichen Relationen/Auto-Id-Verwaltungstabelle (=deine "eingabe_alle").
Wenn die aber letzten Endes sich alle mit der gleichen Struktur abfackeln ließen, dann würde ich eher EINE Detail- bzw. Parameter-Tabelle anlegen mit einem zusätzlichen Feld "Eingabe-Art" (oder so) mit den Fixwerten "DC" "Antenne", "bla", "blubb"....
Müsste man/frau mal drüberschauen.
Zu dem Statement selbst:
Was mir fachlich eher Bullsh^H^H betrachtenswert erscheint ist das merkwürdige Konstrukt mit
dem INNER JOIN der (Haupt-)Tabelle "dev" eigentlich bezogen auf "eingabe_allgemein"
ABER zu meiner Verwunderung mit der Klausel "on dev.id=eingabe_alle.prdid" ....
*kopfkratz
IMHO müsste richtigerweise der Bezug (also der Tabellenname in der Klammer nach dem INNER JOIN) auch "eingabe_alle" heißen und alle weiteren Tabellen sukzessive jeweils noch das Ganze um einen LEFT JOIN ausweiten.
Was ich meinte mit "ein JOIN bezieht sich immer niur auf zwei Tabellen" war, das z.B durch das erste LEFT JOIN ("eingabe_alle" mit "eingabe_allgemein") eine namenlose breitere Tabelle bereitgestellt wird auf die wiederun das nächste LEFT JOIN ("eingabe_dc") Bezug nimmt usw.
Grüße
Biber
also: grundsätzlich bin ich schon relativ sicher, dass die von mir skizzierte Syntax formal richtig ist.
Was die Sinnhaftigkeit/Notwendigkeit Deiner SEHR ausgeprägten Zerfaserung der Detailwerte angeht... das ließe sich eher beurteilen, wenn die Tabellen mal auf dem Tisch lägen.
Wenn die alle eine total unterschiedliche Struktur haben (sollten), dann besteht ein gewisser Zwang zu einer Tabelle für "eingabe_dc-Parameter" und einer Tabelle für "eingabe_Antennen-parameter" etc. etc.. Und dann leider auch der Druck zu einer künstlichen Relationen/Auto-Id-Verwaltungstabelle (=deine "eingabe_alle").
Wenn die aber letzten Endes sich alle mit der gleichen Struktur abfackeln ließen, dann würde ich eher EINE Detail- bzw. Parameter-Tabelle anlegen mit einem zusätzlichen Feld "Eingabe-Art" (oder so) mit den Fixwerten "DC" "Antenne", "bla", "blubb"....
Müsste man/frau mal drüberschauen.
Zu dem Statement selbst:
Was mir fachlich eher Bullsh^H^H betrachtenswert erscheint ist das merkwürdige Konstrukt mit
dem INNER JOIN der (Haupt-)Tabelle "dev" eigentlich bezogen auf "eingabe_allgemein"
ABER zu meiner Verwunderung mit der Klausel "on dev.id=eingabe_alle.prdid" ....
*kopfkratz
IMHO müsste richtigerweise der Bezug (also der Tabellenname in der Klammer nach dem INNER JOIN) auch "eingabe_alle" heißen und alle weiteren Tabellen sukzessive jeweils noch das Ganze um einen LEFT JOIN ausweiten.
Was ich meinte mit "ein JOIN bezieht sich immer niur auf zwei Tabellen" war, das z.B durch das erste LEFT JOIN ("eingabe_alle" mit "eingabe_allgemein") eine namenlose breitere Tabelle bereitgestellt wird auf die wiederun das nächste LEFT JOIN ("eingabe_dc") Bezug nimmt usw.
Grüße
Biber
Hey Biber,
ich will mal die Tabellen auf den Tisch legen ;).
Hier eine PDF mit den Tabellen und der exotischen Idee der Tabelle eingabe_alles. Hoffe jetzt wird klar, was ich damit anstellen möchte.
http://www.l-p-c.eu/DB-Struktur.pdf
ich will mal die Tabellen auf den Tisch legen ;).
Hier eine PDF mit den Tabellen und der exotischen Idee der Tabelle eingabe_alles. Hoffe jetzt wird klar, was ich damit anstellen möchte.
http://www.l-p-c.eu/DB-Struktur.pdf
Moin LuckyLuke,
danke für die Hintergrundinfo.
Dennoch muss ich nochmal rückfragen, wie denn die Tabelle zu lesen ist.
Wenn die Datensätze (also eine Zeile) in der "eingabe_alles" als gültige Kombination interpretiert werden soll, als z.B. für Produkt 01 wäre eine gültige Kombination, wenn gilt "eingabe_dc" ist 7 (bzw. wasauchimmer in dem Datensatz mit der ID 7 in der "eingabe_dc"-Tabelle steht) UND alle anderen Parameter sind NULL (fachlich: dürfen nicht gesetzt werden)....
Wenn diese Tabelle so zu lesen wäre, dann würde die Struktur Sinn machen.
Falls aber, wie ich eher annehme, für das Produkt XY gilt, es sind 2 "eingabe_opt"-Sätze zugeordnet und 1 "eingabe_dc"-Satz und hiervon drei und davon keiner und insgesamt sollen dann 2+1+3==insgesamt 6 Parameterwerte angezeigt werden mit der Zusatz-Info, die einen sind "optische", die anderen "allgemeine" und wieder andere "dc"-Werte, dann ist die Struktur ineffizient und EINE Detailwert-Tabelle mit den Schlüsseln PrdID+ParameterArt[+LfdNr] wäre wartbarer.
Wie ist denn die Struktur zu lesen - als "Kombination von gleichzeitig gültigen Parameterwerten" oder als "Liste unabhängiger Parameterwerte"?
Grüße
Biber
danke für die Hintergrundinfo.
Dennoch muss ich nochmal rückfragen, wie denn die Tabelle zu lesen ist.
Wenn die Datensätze (also eine Zeile) in der "eingabe_alles" als gültige Kombination interpretiert werden soll, als z.B. für Produkt 01 wäre eine gültige Kombination, wenn gilt "eingabe_dc" ist 7 (bzw. wasauchimmer in dem Datensatz mit der ID 7 in der "eingabe_dc"-Tabelle steht) UND alle anderen Parameter sind NULL (fachlich: dürfen nicht gesetzt werden)....
Wenn diese Tabelle so zu lesen wäre, dann würde die Struktur Sinn machen.
Falls aber, wie ich eher annehme, für das Produkt XY gilt, es sind 2 "eingabe_opt"-Sätze zugeordnet und 1 "eingabe_dc"-Satz und hiervon drei und davon keiner und insgesamt sollen dann 2+1+3==insgesamt 6 Parameterwerte angezeigt werden mit der Zusatz-Info, die einen sind "optische", die anderen "allgemeine" und wieder andere "dc"-Werte, dann ist die Struktur ineffizient und EINE Detailwert-Tabelle mit den Schlüsseln PrdID+ParameterArt[+LfdNr] wäre wartbarer.
Wie ist denn die Struktur zu lesen - als "Kombination von gleichzeitig gültigen Parameterwerten" oder als "Liste unabhängiger Parameterwerte"?
Grüße
Biber
Guten Morgen Biber ;)!
Ja genau, deine zweite Annahme ist richtig.
Ich will das ganze Mal näher beschreiben:
Es gibt für jedes Produkt (Tabelle "edv_prdNr" => 01, 02, 03, ...), zugewiesen Werte. Diese Werte stehen in vier Kategorisierungen: Allgemein - DC - HF - Optisch - Antennen.
In einem Webinterface greifen Skripte zur Eingabe (und dementsprechend auch Ausgabe und Bearbeiten) auf die Datenbanktabellen zu und füllen (bearbeiten oder geben) die ausgewählten Spalten aus.
Damit die Verwaltbarkeit für die Nachwelt einfacher ist und neue Parameter auch direkt in MySQL eingefügt werden können, habe ich mir überlegt die Parameter übersichtlich zu kategorisieren und dann, mit der eigentlichen Haupttabelle (edv_prdNr), zu einer ... ja Verwaltungstabelle ("eingabe_alle") zu verknüpfen.
Nach meinem Verständnis sollte die Ausgabe der Verwaltungstabelle so aussehen:
Für Produkt 01 werden diese Werte aus den Tabellen ausgelsen,
=> allgemein_01
=> allgemein_02
=> allgemein_04
=> dc_07
=> hf_08
=> optisch_01
=> antennen_10
Ich hoffe jetzt sind meine Absichten klar, was ich damit bewirken möchte.
Gruß, Luke.
Ja genau, deine zweite Annahme ist richtig.
Ich will das ganze Mal näher beschreiben:
Es gibt für jedes Produkt (Tabelle "edv_prdNr" => 01, 02, 03, ...), zugewiesen Werte. Diese Werte stehen in vier Kategorisierungen: Allgemein - DC - HF - Optisch - Antennen.
In einem Webinterface greifen Skripte zur Eingabe (und dementsprechend auch Ausgabe und Bearbeiten) auf die Datenbanktabellen zu und füllen (bearbeiten oder geben) die ausgewählten Spalten aus.
Damit die Verwaltbarkeit für die Nachwelt einfacher ist und neue Parameter auch direkt in MySQL eingefügt werden können, habe ich mir überlegt die Parameter übersichtlich zu kategorisieren und dann, mit der eigentlichen Haupttabelle (edv_prdNr), zu einer ... ja Verwaltungstabelle ("eingabe_alle") zu verknüpfen.
Nach meinem Verständnis sollte die Ausgabe der Verwaltungstabelle so aussehen:
Für Produkt 01 werden diese Werte aus den Tabellen ausgelsen,
=> allgemein_01
=> allgemein_02
=> allgemein_04
=> dc_07
=> hf_08
=> optisch_01
=> antennen_10
Ich hoffe jetzt sind meine Absichten klar, was ich damit bewirken möchte.
Gruß, Luke.
Moin LuckyLuke,
wenn das die Ausgabe sein soll:
=> allgemein_01
=> allgemein_02
=> allgemein_04
=> dc_07
=> hf_08
=> optisch_01
=> antennen_10
,,,dann würde ich es für sinnvoller halten, wenn diese Informationen in EINER "prd_Parameterwerte"-Tabelle verwaltet werden.
Und die Tabellenstruktur "Prd_ParaWerte" wäre (wie oben angedeutet) in etwa so
[PK] => prdid .........[Foreignkey, zeigt auf den Haupt-Satz=die ProduktId]
[PK] => Parametertyp...z.B. ein Typkennz für "allgemein", eins für "dc"....
[PK] => Parameter-Id... z.B. 07
[ggf.======> Nutz-Infos wie Bemerkung, Erfassunsdatum,...]
Anmerkung zu "ParameterTyp": z.B. Typ "1" kann für Typ "allgemein" stehen, "2" für "dc" oder wie auch immer die Anzeige-Reihenfolge sein soll.
Die eigentlichen Informationen zu den Parameterwerten stünden dann in einer "ParamWerte"-Tabelle
[PK] => ParameterTyp => z.B. 1 für allgemein, 2 für dc....
[PK] => ParameterID => ob AutoWert oder manuell festgelegt ist egal, nur die Kombinaion TYP+ID muss unique sein.
[NutzInfo-Felder:
...Attribute der Kombination "Typ Allg" und "ID=04",
...
]
So hätte ich die Tabellenstruktur skizziert.
Grüße
Biber
wenn das die Ausgabe sein soll:
=> allgemein_01
=> allgemein_02
=> allgemein_04
=> dc_07
=> hf_08
=> optisch_01
=> antennen_10
,,,dann würde ich es für sinnvoller halten, wenn diese Informationen in EINER "prd_Parameterwerte"-Tabelle verwaltet werden.
Und die Tabellenstruktur "Prd_ParaWerte" wäre (wie oben angedeutet) in etwa so
[PK] => prdid .........[Foreignkey, zeigt auf den Haupt-Satz=die ProduktId]
[PK] => Parametertyp...z.B. ein Typkennz für "allgemein", eins für "dc"....
[PK] => Parameter-Id... z.B. 07
[ggf.======> Nutz-Infos wie Bemerkung, Erfassunsdatum,...]
Anmerkung zu "ParameterTyp": z.B. Typ "1" kann für Typ "allgemein" stehen, "2" für "dc" oder wie auch immer die Anzeige-Reihenfolge sein soll.
Die eigentlichen Informationen zu den Parameterwerten stünden dann in einer "ParamWerte"-Tabelle
[PK] => ParameterTyp => z.B. 1 für allgemein, 2 für dc....
[PK] => ParameterID => ob AutoWert oder manuell festgelegt ist egal, nur die Kombinaion TYP+ID muss unique sein.
[NutzInfo-Felder:
...Attribute der Kombination "Typ Allg" und "ID=04",
...
]
So hätte ich die Tabellenstruktur skizziert.
Grüße
Biber
Hallo Biber,
habe mir deinen Vorschlag skizziert, da ich noch nicht so ganz dahinter gestiegen bin.
Hier mal der Screenshot:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Mit PK meinst du sicherlich Primary-Key? Ist denn nicht nur einer pro Tabelle erlaubt?
Foreign Key ist in dem Fall sicherlich der Fremdschlüßel?
Wie meinst du das mit der parameterid in der Tabelle prd_parawerte? Was für eine ID ist das?
Sehe ich das richtig, dass die Tabelle parawerte alle Werte enthält, die ich in meiner Struktur in den fünf einzelnen Tabellen hatte? Und diese parameterid aus prd_parawerte verweist dann darauf?
Fragen über Fragen, da mir das ganze noch etwas unklar ist..
Gruß, Luke.
habe mir deinen Vorschlag skizziert, da ich noch nicht so ganz dahinter gestiegen bin.
Hier mal der Screenshot:
http://www.magix-photos.com/mediapool11/95/8A/5B/D0/1B/EE/11/DA/96/60/D ...
Mit PK meinst du sicherlich Primary-Key? Ist denn nicht nur einer pro Tabelle erlaubt?
Foreign Key ist in dem Fall sicherlich der Fremdschlüßel?
Wie meinst du das mit der parameterid in der Tabelle prd_parawerte? Was für eine ID ist das?
Sehe ich das richtig, dass die Tabelle parawerte alle Werte enthält, die ich in meiner Struktur in den fünf einzelnen Tabellen hatte? Und diese parameterid aus prd_parawerte verweist dann darauf?
Fragen über Fragen, da mir das ganze noch etwas unklar ist..
Gruß, Luke.
Moin LuckyLuke,
die entscheidenden Fragen zuerst:
Aber der kann eine Kombination aus mehreren Feldern sein.
Sag ich unten noch etwas dazu.
Nochmal kurz zu den Begrifflichkeiten.
PK=Primary Key soll sicherstellen, dass jeder Datensatz (jede ArtNr oder Kundennr oder PrdNr) nur einmalig vorkommt.
In Deiner Tabelle PRDIDs hast Du überflüssigerweise eine zusätzliche künstliche ID in der Tabelle, obwohl auch die PrdNr selbst als PK geeignet wäre.
In diesem Fall bezeichnet man/frau den ebenfalls eindeutig identifizierenden Zweit-Shlüssel als Alternate Key.
Ein FK oder ForeignKey oder Fremdschlüssel ist ein Wert in einer Tabelle, der auf einen existierenden Satz mit dem gleichen Wert in einer anderen Tabelle verweist.
Und in der Zuordnungstabelle PrdNr_Parameterwerte können nur Sätze eingegeben werden, zu denen eine PrdNr existiert in der PrdNr-Tabelle und in denen die Kombination ParamTyp+ParamVariante) in der Tabelle "vorhandene ParamWerte" existiert.
Also wäre folgendes Konstrukt denkbar:
Tabelle PrdNr (Felder PrdNr[PK], PrdBez, PrdDetails...)
=> 01; Produkt X ; ProduktX-Details...
=> 06; Produkt Y ; ProduktY-Details...
=> 38; Produkt X ; ProduktX-Details...
Tabelle "vorhandene ParamWerte" (ParamTyp, ParamVariante, ParamDetails...) PK ist ParamTyp+ParamVariante
==> 1; 1; "Details zu der Kombination ParamTyp 1 (allg) Variante 1 "
==> 1; 2; "Details zu der Kombination ParamTyp 1 (allg) Variante 2 "
==> 2; 1; "Details zu der Kombination ParamTyp 2 (dc) Variante 1 "
==> 2; 2; "Details zu der Kombination ParamTyp 2 (dc) Variante 2 "
==> 4; 1; "Details zu der Kombination ParamTyp 4 (optisch) Variante 1 "
...
==> 5; 99; "Details zu der Kombination ParamTyp 5 (turbo) Variante 99 "
Dann können/brauchen in der sehr schlanken Zuordnungstabelle nur die "PRDNr" und "ParamTyp+ParamVariante" als Felder gepflegt werden.
Tabelle PRDNr_ParamWerte (Felder PRDNr; ParamTyp;ParamVariante) Alles zusammen ist PK
=> 01; 1, 1
=> 01, 4, 7
---> diese beiden Datensätze hätten den Informationsgehalt
PRDNr 01 hat zugeordnet vom ParamTyp 1 (allg) die Variante 1
PRDNr 01 hat zugeordnet vom ParamTyp 4 (optisch) die Variante 7
...und Details zu der PRDNr stehen in der PrdNr-Tabelle und Details zu den Param-Werten in der Tabelle "vorhandene ParamWerte" .
Grüße
Biber
die entscheidenden Fragen zuerst:
Mit PK meinst du sicherlich Primary-Key?
Jepp.Ist denn nicht nur einer pro Tabelle erlaubt?
Doch. Es ist nur ein PrimaryKey (ein eindeutiger Schlüssel) pro Tabelle erlaubt.Aber der kann eine Kombination aus mehreren Feldern sein.
Sag ich unten noch etwas dazu.
Foreign Key ist in dem Fall sicherlich der Fremdschlüssel?
Jepp.Nochmal kurz zu den Begrifflichkeiten.
PK=Primary Key soll sicherstellen, dass jeder Datensatz (jede ArtNr oder Kundennr oder PrdNr) nur einmalig vorkommt.
In Deiner Tabelle PRDIDs hast Du überflüssigerweise eine zusätzliche künstliche ID in der Tabelle, obwohl auch die PrdNr selbst als PK geeignet wäre.
In diesem Fall bezeichnet man/frau den ebenfalls eindeutig identifizierenden Zweit-Shlüssel als Alternate Key.
Ein FK oder ForeignKey oder Fremdschlüssel ist ein Wert in einer Tabelle, der auf einen existierenden Satz mit dem gleichen Wert in einer anderen Tabelle verweist.
Und in der Zuordnungstabelle PrdNr_Parameterwerte können nur Sätze eingegeben werden, zu denen eine PrdNr existiert in der PrdNr-Tabelle und in denen die Kombination ParamTyp+ParamVariante) in der Tabelle "vorhandene ParamWerte" existiert.
Also wäre folgendes Konstrukt denkbar:
Tabelle PrdNr (Felder PrdNr[PK], PrdBez, PrdDetails...)
=> 01; Produkt X ; ProduktX-Details...
=> 06; Produkt Y ; ProduktY-Details...
=> 38; Produkt X ; ProduktX-Details...
Tabelle "vorhandene ParamWerte" (ParamTyp, ParamVariante, ParamDetails...) PK ist ParamTyp+ParamVariante
==> 1; 1; "Details zu der Kombination ParamTyp 1 (allg) Variante 1 "
==> 1; 2; "Details zu der Kombination ParamTyp 1 (allg) Variante 2 "
==> 2; 1; "Details zu der Kombination ParamTyp 2 (dc) Variante 1 "
==> 2; 2; "Details zu der Kombination ParamTyp 2 (dc) Variante 2 "
==> 4; 1; "Details zu der Kombination ParamTyp 4 (optisch) Variante 1 "
...
==> 5; 99; "Details zu der Kombination ParamTyp 5 (turbo) Variante 99 "
Dann können/brauchen in der sehr schlanken Zuordnungstabelle nur die "PRDNr" und "ParamTyp+ParamVariante" als Felder gepflegt werden.
Tabelle PRDNr_ParamWerte (Felder PRDNr; ParamTyp;ParamVariante) Alles zusammen ist PK
=> 01; 1, 1
=> 01, 4, 7
---> diese beiden Datensätze hätten den Informationsgehalt
PRDNr 01 hat zugeordnet vom ParamTyp 1 (allg) die Variante 1
PRDNr 01 hat zugeordnet vom ParamTyp 4 (optisch) die Variante 7
...und Details zu der PRDNr stehen in der PrdNr-Tabelle und Details zu den Param-Werten in der Tabelle "vorhandene ParamWerte" .
Grüße
Biber
Hey Biber!!!
Viele Dank, habe mir mal dein Schema an meins angewandt aufgezeichnet und blicke endlich durch. Klasse Lösung.
Habe nun versucht mit dem JOIN Befehl dies zu verknüpfen, damit das auch so ausgegeben wird in PHP:
SELECT dev_produkte.prdNr, prd_parameter.parameter, prd_parawert.parameterwert
FROM dev_produkte
INNER JOIN prd_parawert ON dev_produkte.id = prd_parawert.prdid
AND prd_parameter.para_id = prd_parawert.para_id
Doch ich erhalte folgende Fehlermeldung:
"#1054 - Unknown column 'prd_parameter.parameter' in 'field list'"
Ohne 'prd_parameter.parameter' erhalte ich die richtige Ausgabe.
Gruß, Luke.
Viele Dank, habe mir mal dein Schema an meins angewandt aufgezeichnet und blicke endlich durch. Klasse Lösung.
Habe nun versucht mit dem JOIN Befehl dies zu verknüpfen, damit das auch so ausgegeben wird in PHP:
SELECT dev_produkte.prdNr, prd_parameter.parameter, prd_parawert.parameterwert
FROM dev_produkte
INNER JOIN prd_parawert ON dev_produkte.id = prd_parawert.prdid
AND prd_parameter.para_id = prd_parawert.para_id
Doch ich erhalte folgende Fehlermeldung:
"#1054 - Unknown column 'prd_parameter.parameter' in 'field list'"
Ohne 'prd_parameter.parameter' erhalte ich die richtige Ausgabe.
Gruß, Luke.
Moin LuckyLuke,
sorry, hätte ich vielleicht erwähnen sollen -einen JOIN brauchst Du nun auch nicht mehr.
Kannst was Schnelleres nehmen..*gg
Ein JOIN ohne Feld "prd_parameter.paramID" in der "ON"-Clause würde laufen, denn die Parent-Tabelle PrdNr enthält ja in der Tat kein Feld dieses Namens.
Aber, wie gesagt, es ginge ja jetzt mit einer normalen (schnelleren) WHERE-Clause.
[ungetestet und Feldnamen "ParamTyp" geraten]
Übereinstimmen müssen
Aber: So erhältst Du auch nur Produkte, für die es Parameterwerte gibt. PrdIds OHNE zugeordnete Werte werden nicht angezeigt.
Das wiederum ginge mit einem LEFT JOIN und der PrdId-Tabelle als "führender" Tabelle.
Sonst (wenn es nicht klappt) poste bitte die drei CREATE TABLE-Statements, dann habe ich die richtigen Feldnamen.
Grüße
Biber
sorry, hätte ich vielleicht erwähnen sollen -einen JOIN brauchst Du nun auch nicht mehr.
Kannst was Schnelleres nehmen..*gg
Ein JOIN ohne Feld "prd_parameter.paramID" in der "ON"-Clause würde laufen, denn die Parent-Tabelle PrdNr enthält ja in der Tat kein Feld dieses Namens.
Aber, wie gesagt, es ginge ja jetzt mit einer normalen (schnelleren) WHERE-Clause.
SELECT PW.prdid, Dev.PRDBezeichnung, PAR.parameter, PW.parameterwert
FROM prd_parawert PW, dev_produkte Dev, prd_parameter PAR
WHERE PW.prdid = Dev.id
AND PW.para_id = PAR.para_id
And PW.paramTYP=PAR.ParamTyp
[ order by PW. PrdId, PW.ParamTyp...][ungetestet und Feldnamen "ParamTyp" geraten]
Übereinstimmen müssen
- die PrdId (... PW.prdid = Dev.id )
- die beiden Schlüssel in der Zuordnungstabelle "parameterWert" und "Parameter(stamm)" : ...PW.para_id = PAR.para_id And PW.paramTYP=PAR.ParamTyp
Aber: So erhältst Du auch nur Produkte, für die es Parameterwerte gibt. PrdIds OHNE zugeordnete Werte werden nicht angezeigt.
Das wiederum ginge mit einem LEFT JOIN und der PrdId-Tabelle als "führender" Tabelle.
Sonst (wenn es nicht klappt) poste bitte die drei CREATE TABLE-Statements, dann habe ich die richtigen Feldnamen.
Grüße
Biber
Hmm, also das mit dem SELECT blick ich jetzt nicht...
Hier mal die CREATE TABLE-Statements:
1. edv_produkte
CREATE TABLE dev_produkte (
id int(6) NOT NULL,
prdNr int(6) NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
2. prd_kat
CREATE TABLE prd_kat (
prdkat_id int(6) NOT NULL,
parakategorie varchar(60) collate utf8_bin NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle 'prd_kat'
--
INSERT INTO prd_kat (prdkat_id, parakategorie) VALUES
(1, 'allgemein'),
(2, 'dc'),
(3, 'hf'),
(4, 'optisch'),
(5, turbo);
3. prd_parameter
CREATE TABLE prd_parameter (
prd_kategorie int(6) NOT NULL,
para_id int(6) NOT NULL,
parameter varchar(80) collate utf8_bin NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle 'prd_parameter'
--
INSERT INTO prd_parameter (prd_kategorie, para_id, parameter) VALUES
(1, 1, 'allgemein_01'),
(1, 2, 'allgemein_02'),
(2, 1, 'hf_01'),
(2, 2, 'hf_02'),
(3, 1, 'dc_01'),
(3, 2, 'dc_02'),
(4, 1, 'optisch_01'),
(4, 2, 'optisch_02'),
(5, 1, 'turbo_01'),
(5, 2, 'turbo_02');
4. prd_parawert
CREATE TABLE prd_parawert (
prdid int(6) NOT NULL,
prdkat_id int(6) NOT NULL,
para_id int(6) NOT NULL,
parameterwert varchar(6) collate latin1_general_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
--
-- Daten für Tabelle 'prd_parawert'
--
INSERT INTO prd_parawert (prdid, prdkat_id, para_id, parameterwert) VALUES
(1, 1, 1, 'TESTWERT1');
Hoffe du kannst damit was anfangen.
Hier mal die CREATE TABLE-Statements:
1. edv_produkte
CREATE TABLE dev_produkte (
id int(6) NOT NULL,
prdNr int(6) NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
2. prd_kat
CREATE TABLE prd_kat (
prdkat_id int(6) NOT NULL,
parakategorie varchar(60) collate utf8_bin NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle 'prd_kat'
--
INSERT INTO prd_kat (prdkat_id, parakategorie) VALUES
(1, 'allgemein'),
(2, 'dc'),
(3, 'hf'),
(4, 'optisch'),
(5, turbo);
3. prd_parameter
CREATE TABLE prd_parameter (
prd_kategorie int(6) NOT NULL,
para_id int(6) NOT NULL,
parameter varchar(80) collate utf8_bin NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
--
-- Daten für Tabelle 'prd_parameter'
--
INSERT INTO prd_parameter (prd_kategorie, para_id, parameter) VALUES
(1, 1, 'allgemein_01'),
(1, 2, 'allgemein_02'),
(2, 1, 'hf_01'),
(2, 2, 'hf_02'),
(3, 1, 'dc_01'),
(3, 2, 'dc_02'),
(4, 1, 'optisch_01'),
(4, 2, 'optisch_02'),
(5, 1, 'turbo_01'),
(5, 2, 'turbo_02');
4. prd_parawert
CREATE TABLE prd_parawert (
prdid int(6) NOT NULL,
prdkat_id int(6) NOT NULL,
para_id int(6) NOT NULL,
parameterwert varchar(6) collate latin1_general_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
--
-- Daten für Tabelle 'prd_parawert'
--
INSERT INTO prd_parawert (prdid, prdkat_id, para_id, parameterwert) VALUES
(1, 1, 1, 'TESTWERT1');
Hoffe du kannst damit was anfangen.
Moin LuckyLuke,
und was ist jetzt das Problem?
Wenn ich meine Abfrage von oben nehme, die Feldnamen anpasse und meinetwegen noch die Tabelle prd_hat als vierte Tabelle dazunehme erhalte ich:
(Feld DEV.PrdBez mit Produktbezeichnung habe ich dazugenommen)
...dann erhalte ich:
Drei Anmerkungen noch:
Zu letztem Punkt bitte kurz die mySQL-Referenz konsultieren, z.B nach "ForeignKey", "Constraint" oder "cascading delete" suchen. [Das sprengt den Thread hier].
Grüße
Biber
und was ist jetzt das Problem?
Wenn ich meine Abfrage von oben nehme, die Feldnamen anpasse und meinetwegen noch die Tabelle prd_hat als vierte Tabelle dazunehme erhalte ich:
(Feld DEV.PrdBez mit Produktbezeichnung habe ich dazugenommen)
SELECT PW.prdid, Dev.PrdNr, Dev.PRDBez, KAT.parakategorie, PAR.parameter, PW.parameterwert
FROM prd_parawert PW, dev_produkte Dev, prd_parameter PAR, prd_kat KAT
WHERE PW.prdid = Dev.id
AND PW.para_id = PAR.para_id
And PW.prdkat_id=PAR.prd_kategorie
and PW.Prdkat_id=KAT.prdkat_id
order by PrdId, PW.Prdkat_id| prdid | PrdNr | PRDBez | parakategorie | parameter | parameterwert |
| 1 | 10 | prd10 | Allgemein | allgemein_01 | TESTWert1 |
Drei Anmerkungen noch:
- Deine Feldnamen sind wirklich....schwer zu merken und auseinanderzuhalten. Es ist nur noch unter TSO/MVS und bei steinalten dBASEIII-Datenformaten nötig, sich selbst derartige Prefix/Suffix/Abkürzungsarien anzutun.
- Die Tabelle DEV (dev_produkte) hat IMHO keine ID nötig, denn die PrdNr ist sicher genauso eindeutig und hat höheren Erkennungswert. Denn sicherlich hat niemand bei euch Lust, irgendwelche neuen Autoincrementwerte (diese prdIds) für eure Produkte zu lernen.
- Foreignkeys "denkt" man/frau sich nicht nur, sondern definiert sie auch in den CREATE-TABLE-Statements. Sinn: die Datenbank(engine) selbst soll ja die Konsistenz der Tabelleninhalte überwachen/ungültige Eingaben abblocken etc.
Zu letztem Punkt bitte kurz die mySQL-Referenz konsultieren, z.B nach "ForeignKey", "Constraint" oder "cascading delete" suchen. [Das sprengt den Thread hier].
Grüße
Biber
Guuten Morgen Biber und
VIELEN DANK für deine technische Unterstützung. Super, es geht alles und klar: ist analog zu deinem vorherigen Post, war gestern wohl doch schon zuviel des Guten. Danke dir ;).
Wenn ich mir meine alte DB-Struktur so ansehe, stellen sich mir jetzt meine Nackenhaare auf...
Top FORUM hier, nochmal thx Biber
.
Gruß, Luke.
VIELEN DANK für deine technische Unterstützung. Super, es geht alles und klar: ist analog zu deinem vorherigen Post, war gestern wohl doch schon zuviel des Guten. Danke dir ;).
Wenn ich mir meine alte DB-Struktur so ansehe, stellen sich mir jetzt meine Nackenhaare auf...
Top FORUM hier, nochmal thx Biber
.Gruß, Luke.
Eine Frage habe ich noch:
In meinem PHP-Skript wird die Produktnummer wird in einem DropDown Menü ausgewählt. Nach Auswahl wird dann der Inhalt der Tabelle prd_parawert ausgegeben.
Ich möchte nun alle Produktnummer in das Drop Down laden und nach Auswahl einer Produktnummer, soll dann die Verknüpfung ausgegeben werden.
Lässt sich ein Vergleich in der bereits vorhandenen SELECT-Verknüpfung durchführen oder muss eine neue gesonderte SELECT-Anweisung geschrieben werden?
In meinem PHP-Skript wird die Produktnummer wird in einem DropDown Menü ausgewählt. Nach Auswahl wird dann der Inhalt der Tabelle prd_parawert ausgegeben.
Ich möchte nun alle Produktnummer in das Drop Down laden und nach Auswahl einer Produktnummer, soll dann die Verknüpfung ausgegeben werden.
Lässt sich ein Vergleich in der bereits vorhandenen SELECT-Verknüpfung durchführen oder muss eine neue gesonderte SELECT-Anweisung geschrieben werden?
Moin LuckyLuke,
freut mich, wenn es geholfen hat, auch wenn dieser Thread einen etwas anderen Verlauf genommen hat als gedacht.
Zu Deiner Frage "PrdIds (oder doch PrdNrn?) per Dropdown auswählen und in der SELECT-Anweisung verwenden".
Ja, schon.
Aber dann mein oben gepostetes "Aber" berücksichtigen:
Heißt, wenn Du das von mir zuletzt gepostete Statement um eine Bedingung erweiterst...
Ist genau das, was Du für Anzeigen, Listen, Berichte der vollständig erfassten PrdIds brauchst.
Für einen ResultSet, der auch die PrdIds enthält, denen noch gar keine Parameterwerte zugeordnet sind musst Du -auch wie oben beschrieben- einen Select auf die DEV-Tabelle abfeuern und die Dev_Parameterwerte mit einem LEFT JOIN statt einem INNER JOIN dranflanschen.
Hoffe, dass ich Deine Frage richtig verstanden habe und wir diesen Thread jetzt als "hinreichend beantwortet" schließen können.
Grüße
Biber
freut mich, wenn es geholfen hat, auch wenn dieser Thread einen etwas anderen Verlauf genommen hat als gedacht.
Zu Deiner Frage "PrdIds (oder doch PrdNrn?) per Dropdown auswählen und in der SELECT-Anweisung verwenden".
Ja, schon.
Aber dann mein oben gepostetes "Aber" berücksichtigen:
Aber: So erhältst Du auch nur Produkte, für die es Parameterwerte gibt. PrdIds OHNE zugeordnete Werte werden nicht angezeigt.
Das wiederum ginge mit einem LEFT JOIN und der PrdId-Tabelle als "führender" Tabelle.
Das wiederum ginge mit einem LEFT JOIN und der PrdId-Tabelle als "führender" Tabelle.
Heißt, wenn Du das von mir zuletzt gepostete Statement um eine Bedingung erweiterst...
...AND Dev.id IN ( {durch Kommata getrennte Liste der gewählten PrdIDs})
...dann erhält der Resultset nur die PrdIDs, denen auch irgendwo Parameter zugeordnet sind.Ist genau das, was Du für Anzeigen, Listen, Berichte der vollständig erfassten PrdIds brauchst.
Für einen ResultSet, der auch die PrdIds enthält, denen noch gar keine Parameterwerte zugeordnet sind musst Du -auch wie oben beschrieben- einen Select auf die DEV-Tabelle abfeuern und die Dev_Parameterwerte mit einem LEFT JOIN statt einem INNER JOIN dranflanschen.
Hoffe, dass ich Deine Frage richtig verstanden habe und wir diesen Thread jetzt als "hinreichend beantwortet" schließen können.
Grüße
Biber
Hey Biber,
also ich habe mir das viel einfacher vorgestellt.
Kann ich in die SELECT-Abfrage, die die Tabllen miteinander verknüpft, nicht folgendes hinzufügen "AND Dev.prdNr = '$prd_ddm'" ($prd_ddm ist das Array mit allen enthaltenden Produktnummern einer zweiten SELECT-Anweisung, die nur für das auslesen der Produktnummern zuständig ist) und wird später in der Ausgabe wiefolgt verglichen und ausgegeben, wenn die Dev.prdNr richtig ist:
if ($prdNr == $prd_ddm)
{
...
}
Oder ist dieser Weg falsch?
Eine Verständnisfrage zu deinem Beitrag
Heißt im Klartext: Dev.PrdNr wird mit PAR.parameter über LEFT-JOIN verbunden, dabei fällt die SELECT-Verknüpfung weg?
Gruß, Luke.
also ich habe mir das viel einfacher vorgestellt.
Kann ich in die SELECT-Abfrage, die die Tabllen miteinander verknüpft, nicht folgendes hinzufügen "AND Dev.prdNr = '$prd_ddm'" ($prd_ddm ist das Array mit allen enthaltenden Produktnummern einer zweiten SELECT-Anweisung, die nur für das auslesen der Produktnummern zuständig ist) und wird später in der Ausgabe wiefolgt verglichen und ausgegeben, wenn die Dev.prdNr richtig ist:
if ($prdNr == $prd_ddm)
{
...
}
Oder ist dieser Weg falsch?
Eine Verständnisfrage zu deinem Beitrag
Für einen ResultSet, der auch die PrdIds enthält, denen noch gar keine Parameterwerte >zugeordnet sind musst Du -auch wie oben beschrieben- einen Select auf die DEV-Tabelle >abfeuern und die Dev_Parameterwerte mit einem LEFT JOIN statt einem INNER JOIN >dranflanschen.
Heißt im Klartext: Dev.PrdNr wird mit PAR.parameter über LEFT-JOIN verbunden, dabei fällt die SELECT-Verknüpfung weg?
Gruß, Luke.
Moin LuckyLuke,
Also:
Aber sicherlich verfügt PHP über eine Funktion "ArrayToString()" oder so ähnlich.
Und im Statement selbst wäre eben das lesbarste die Syntax "..AND Dev.prdNR IN ( prd1, prd2, prd6) ".
Also "..AND Dev.prdNR IN {deineZweiteSelectAnweisung} ".
Die Frage nach dem LEFT JOIN...oben hattest Du dieses Statement gepostet:
Genau dieses mit einem LEFT JOIN statt einem INNER JOIN, also "prd_parameter"-Werte dürfen auch fehlen, aber alle DEV-Datensätze sollen geholt werden.
Grüße
Biber
also ich habe mir das viel einfacher vorgestellt.
Noch einfacher? Noch bis Du jung genug für eine Umschulung zum Bäcker... Also:
Kann ich nicht...nicht folgendes hinzufügen "AND Dev.prdNr = '$prd_ddm'" ($prd_ddm ist das Array mit allen enthaltenden Produktnummern
Doch, im Prinzp schon. Nur das Array selbst musst Du in eine Strimgvariable umwandeln. Inhalt ist der gleiche, aber ein String "prd1, prd2, prd6" kann in einem erzeugten Statement eingebaut werden, ein Datentyp Array IMHO nicht. [Vielleicht erlauben das PHP/mySQL auch, da bin ich kein Fachmann].Aber sicherlich verfügt PHP über eine Funktion "ArrayToString()" oder so ähnlich.
Und im Statement selbst wäre eben das lesbarste die Syntax "..AND Dev.prdNR IN ( prd1, prd2, prd6) ".
einer zweiten SELECT-Anweisung, die nur für das auslesen der Produktnummern zuständig ist)
Oder aber Du verwendest direkt diese zweite SELECT-Anweisung anstelle des plattgedrückten Resultsets.Also "..AND Dev.prdNR IN {deineZweiteSelectAnweisung} ".
Die Frage nach dem LEFT JOIN...oben hattest Du dieses Statement gepostet:
SELECT dev_produkte.prdNr, prd_parameter.parameter, prd_parawert.parameterwert
FROM dev_produkte
INNER JOIN prd_parawert ON dev_produkte.id = prd_parawert.prdid
AND prd_parameter.para_id = prd_parawert.para_idGenau dieses mit einem LEFT JOIN statt einem INNER JOIN, also "prd_parameter"-Werte dürfen auch fehlen, aber alle DEV-Datensätze sollen geholt werden.
Grüße
Biber
Moin Biber ;),
so nach einer kleinen Pause bin ich wieder da.
Ja ich glaub auch, ich hätte besser Bäcker werden sollen
Ich habe es in den letzten zwei Tagen mit "AND ... IN (...)" versucht, doch so wirklich wurde das alles nicht.
Wenn ich mir die Ausgabe unter MySQL so anschaue bezweifle ich allmählich auch, dass es so geht wie ich es mir vorstelle.
Momentane Ausgabe ist folgende: http://l-p-c.uttx.net/Problem.JPG
Darin ist auch veranschaulicht, wie es aussehen soll.
Kann man ein GROUP BY bzw. DISTINCT nur auf die Spalte PW.prdid anwenden, ohne das die anderen Spalten in mitleidenschaft gezogen werden, sprich alle ausgegeben werden, dafür die zugehörige eindeutige PrdNr nur einmal angezeigt wird?
Gruß, Luke.
so nach einer kleinen Pause bin ich wieder da.
Ja ich glaub auch, ich hätte besser Bäcker werden sollen
Ich habe es in den letzten zwei Tagen mit "AND ... IN (...)" versucht, doch so wirklich wurde das alles nicht.
Wenn ich mir die Ausgabe unter MySQL so anschaue bezweifle ich allmählich auch, dass es so geht wie ich es mir vorstelle.
Momentane Ausgabe ist folgende: http://l-p-c.uttx.net/Problem.JPG
Darin ist auch veranschaulicht, wie es aussehen soll.
Kann man ein GROUP BY bzw. DISTINCT nur auf die Spalte PW.prdid anwenden, ohne das die anderen Spalten in mitleidenschaft gezogen werden, sprich alle ausgegeben werden, dafür die zugehörige eindeutige PrdNr nur einmal angezeigt wird?
Gruß, Luke.
Moin LuckyLuke,
uuups, was ist denn da passiert? *gg
Kannst Du bitte noch mal das Statement posten, mit dem dieses Ergebnis rauskommt?
So sollte es wirklich nicht bleiben...
Grüße
Biber
uuups, was ist denn da passiert? *gg
Kannst Du bitte noch mal das Statement posten, mit dem dieses Ergebnis rauskommt?
So sollte es wirklich nicht bleiben...
Grüße
Biber
Hehe ja, das sieht bissi seltsam aus.
Hier der PHP-Befehl:
<?php
error_reporting(E_ALL);
Verbindungsdaten zur Datenbank und deren Datenbanktabellen \\
require("db.inc.php");
*** \\
$res=mysql_db_query("datenbank_dev", "SELECT Dev.prdNr, PAR.parameter, PW.parameterwert
FROM prd_parawert PW, dev_produkte Dev, prd_parameter PAR, prd_kat KAT
WHERE PW.prdid = Dev.id
AND PW.para_id = PAR.para_id
AND PW.prdkat_id = PAR.prd_kategorie
AND PW.Prdkat_id = KAT.prdkat_id
ORDER BY prdid, PW.Prdkat_id");
while($row=mysql_fetch_array($res,MYSQL_NUM))
{
$pr_nrn=$row;
if(isset($_GET['produkt']) && $_GET['produkt']==$row)
{
$zeige_produkt=$row;
}
}
Drop Down Menü wird mit Produktnummern gefüllt
echo '
<form name="produktwahl" method="get" action="'.$_SERVER['PHP_SELF'].'">
<select name="produkt" onchange="document.produktwahl.submit()">
<option value="-1">Bitte wählen</option><option value="-1"></option>';
for($z=0;$z<count($pr_nrn);$z++)
{
if(isset($_GET['produkt']) && $_GET['produkt']==$pr_nrn[$z])
{
echo '<option value="'.$pr_nrn[$z].'" selected>'.$pr_nrn[$z].'</option>';
}
else
{
echo '<option value="'.$pr_nrn[$z].'">'.$pr_nrn[$z].'</option>';
}
}
echo '</select></form>';
Wenn ein Produkt gewählt wurde, zeige es in einer Tabellenzeile
if(isset($zeige_produkt))
{
for($z=0;$z<count($zeige_produkt);$z++)
{
echo ' '.$zeige_produkt[$z].'<br>';
}
}
?>
Hier der PHP-Befehl:
<?php
error_reporting(E_ALL);
Verbindungsdaten zur Datenbank und deren Datenbanktabellen \\
require("db.inc.php");
*** \\
$res=mysql_db_query("datenbank_dev", "SELECT Dev.prdNr, PAR.parameter, PW.parameterwert
FROM prd_parawert PW, dev_produkte Dev, prd_parameter PAR, prd_kat KAT
WHERE PW.prdid = Dev.id
AND PW.para_id = PAR.para_id
AND PW.prdkat_id = PAR.prd_kategorie
AND PW.Prdkat_id = KAT.prdkat_id
ORDER BY prdid, PW.Prdkat_id");
while($row=mysql_fetch_array($res,MYSQL_NUM))
{
$pr_nrn=$row;
if(isset($_GET['produkt']) && $_GET['produkt']==$row)
{
$zeige_produkt=$row;
}
}
Drop Down Menü wird mit Produktnummern gefüllt
echo '
<form name="produktwahl" method="get" action="'.$_SERVER['PHP_SELF'].'">
<select name="produkt" onchange="document.produktwahl.submit()">
<option value="-1">Bitte wählen</option><option value="-1"></option>';
for($z=0;$z<count($pr_nrn);$z++)
{
if(isset($_GET['produkt']) && $_GET['produkt']==$pr_nrn[$z])
{
echo '<option value="'.$pr_nrn[$z].'" selected>'.$pr_nrn[$z].'</option>';
}
else
{
echo '<option value="'.$pr_nrn[$z].'">'.$pr_nrn[$z].'</option>';
}
}
echo '</select></form>';
Wenn ein Produkt gewählt wurde, zeige es in einer Tabellenzeile
if(isset($zeige_produkt))
{
for($z=0;$z<count($zeige_produkt);$z++)
{
echo ' '.$zeige_produkt[$z].'<br>';
}
}
?>
