SELECT Query

[GELight]

Einen schönen Samstag euch allen,

Ich versuche seit ein paar Tagen einen SELECT Query ( MySQL ) zu erstellen aber hänge da an einem Problem. Ich weiß auch nicht wirklich, ob das so funktioniert, wie ich es mir wünsche. Aber ich denke doch, dass sowas irgendwie gehen muss.

http://gelight.de/tabellen.gif

Ich habe hier einfach mal meine 2 Tabellen als Bild, damit ihr den Aufbau besser sehen könnt. ( devID_kategorie und devID_beschreibung sind jetzt schon INT und nicht Text, falls das jemandem auffallen sollte hehe ). Okay.. was will ich machen.

Ich möchte meine Systemsteuerungstabelle auslesen.
Nur das am ende nicht:

3 , 56 , _ , 40

...sondern

3 , User Knoten, Rechteverwaltung , _ , Hauptmenü

...als Array zurück gegeben bekomme.
Das Problem liegt nun im Query, den ich erstellen muss.
Ich möchte auch möglichst nur 1 Query erstellen und nicht extra mehrere hintereinander ausführen müssen, da ich das sauberer finde.

Hier wäre mal mein erster Test vom Query.
Dieser holt einfach alles so raus, wie ich es in der Tabelle stehen habe. Soweit so gut.

SELECT           cms_1_systemsteuerung.id,      cms_1_systemsteuerung.devID_kategorie as kategorie,
 cms_1_systemsteuerung.icon,
 cms_1_systemsteuerung.devID_beschreibung as beschreibung
FROM
 cms_1_systemsteuerung

Nun aber kommen die Joins zwischen den zwei Tabellen und da hänge ich an der Schreibweise, da ich ja in meinem SELECT 2x auf die selbe Spalte zugreifen muss... nur halt jeweils über eine andere ID.

Mein letzter Versuch sah so aus.. jedoch ohne Erfolg.
Wobei ich hier schon vermute, dass es nicht wirklich gehen kann, da MySQL ja nicht wissen kann, auf welchen Datensatz sich der jeweilige Zugriff auf "text" bezieht.

SELECT
 #systemsteuerung#.id,
 #sprachentabelle#.text as kategorie,
 #systemsteuerung#.icon,
 #sprachentabelle#.text as beschreibung
FROM
 #systemsteuerung#, #sprachentabelle#
WHERE
 #sprachentabelle#.id = #systemsteuerung#.devID_kategorie AND
 #sprachentabelle#.id = #systemsteuerung#.devID_beschreibung

Wie müsste ich das am besten schreiben, damit ich am Ende
3 , User Knoten, Rechteverwaltung , _ , Hauptmenü
zurück bekomme und er halt statt den IDs die Texte aus der Sprachentabelle einträgt?

Ich hoffe Ihr könnt mir helfen.

Mario

[Vinzenz Mai]

Hallo

http://gelight.de/tabellen.gif
Ich habe hier einfach mal meine 2 Tabellen als Bild, damit ihr den Aufbau besser sehen könnt.

als Text hier gepostet wäre angenehmer :-)

Ich möchte meine Systemsteuerungstabelle auslesen.
Nur das am ende nicht:
3 , 56 , _ , 40

...sondern

3 , User Knoten, Rechteverwaltung , _ , Hauptmenü

Nun aber kommen die Joins zwischen den zwei Tabellen und da hänge ich an der Schreibweise, da ich ja in meinem SELECT 2x auf die selbe Spalte zugreifen muss... nur halt jeweils über eine andere ID.

Ja, das ist gar kein Problem. Du musst nur mit Aliasnamen arbeiten. Siehe dazu
Fortgeschrittene Jointechniken (beim Selfjoin habe ich das auf jeden Fall beschrieben).

Deinen Tabellenaufbau finde ich zwar nicht richtig glücklich, aber Dein derzeitiges Problem läßt sich mit zwei Joins ganz einfach lösen:

SELECT  
    css.id,  
    csp1.text,  
    css.icon,  
    csp2.text  
FROM cms_1_systemsteuerung css  
INNER JOIN cms_1_sprachentabelle csp1 -- verknüpfe hier über die Kategorie  
ON css.devID_kategorie = csp1.id  
INNER JOIN cms_1_sprachentabelle csp2 -- hier über die Beschreibung  
ON css.devID_beschreibung = csp2.id

Dein gewünschtes Ergebnis stimmt übrigens mit Deinen Spaltennamen nicht überein :-)

Empfehlenswert in SELFHTML aktuell:
Einführung in Joins von Rouven Thimm.

Freundliche Grüße

Vinzenz

[GELight]

Hallo Vinzenz,

Danke für den Tipp mit den Joins. Das werd ich auf jeden Fall mal versuchen. Kurz zu meinen Tabellen. Was genau gefällt dir daran nicht?

Mario

[King^Lully]

Kurz zu meinen Tabellen. Was genau gefällt dir daran nicht?

Es sind wohl mehr als 2.
Was gefällt u.a. nicht:

• die Namen der Tabellen
• die Namen der Datenfelder
• der Verweis auf Land in der Sprachentabelle, muesste nicht ein Verweis auf eine Laendertabelle dabei sein?

[GELight]

Hallo King^Lully,

Es sind wohl mehr als 2.

Meinst du mehrer Tabellen? Nein, in diesem Fall sind es nur die zwei.
Ich wollte zB. nicht für jede angelegte Sprache ( also die Übersetzungen  der Texte ) in eine extra DB-Tabelle ablegen. Find ich ziemlich übertrieben, da es em Ende vielleicht 50 - 100 Datensätze werden, vermute ich. Deshalb mache ich nur 1 Sprachentabelle, wo alle drin sind.

Was gefällt u.a. nicht:

• die Namen der Tabellen

Was ist an den Namen auszusetzen? Zu lang?
Der erste Teil der Namen hat auch eine Technische Bewandnis und muss rein. Okay... wenn die Namen ansich zu lang sein sollten... das kann man ja noch kürzen aber MySQL lässt locker 32 Zeichen zu.

• die Namen der Datenfelder

Was würdest du hier evtl. besser vorschlagen? Oder welchen Tipp gibst du mir da? Bin für alles offen und lerne gern dazu...

• der Verweis auf Land in der Sprachentabelle, muesste nicht ein Verweis auf eine Laendertabelle dabei sein?

Wo sollte der hin?

Mario

[King^Lully]

Was gefällt u.a. nicht:

• die Namen der Tabellen

Was ist an den Namen auszusetzen? Zu lang?

"cms_1_systemsteuerung" ist kein vernuenftiger Tabellenname. Wie heisst die DB? "CMS"?

Zudem bildet eine Tabelle dem entity relationship model eine real existierende Entität nach, "systemsteuerung" scheint mir keine solche zu sein.

Der erste Teil der Namen hat auch eine Technische Bewandnis und muss rein.

Nichts muss, alles kann.   ;)

Okay... wenn die Namen ansich zu lang sein sollten... das kann man ja noch kürzen aber MySQL lässt locker 32 Zeichen zu.

Die Länge ist nicht das Problem, aber Namen haben eine wichtige Bedeutung.

• die Namen der Datenfelder

Was würdest du hier evtl. besser vorschlagen? Oder welchen Tipp gibst du mir da? Bin für alles offen und lerne gern dazu...

Ich empfehel die King^Lully Notation:
<Präfix:Tabellenname>_<Datenfeldname("bestmögliche" Bezeichnung für das Attribut wählen!)> (anhängend ggf. bspw. "_ID" bzw. "_UFID" bzw. "_GUID" (Suffix))

• der Verweis auf Land in der Sprachentabelle, muesste nicht ein Verweis auf eine Laendertabelle dabei sein?

Wo sollte der hin?

Mir gigs da um den wichtigen Unterschied zwischen Sprache und Land, habe mich da schlecht ausgedrückt. Hast Du korrekt unterschieden?

[GELight]

Hallo King^Lully,

Länder und Sprachen... hmm.. wenn ich ehrlich bin habe ich da nicht nochmal nach Sprachen unterschieden. Denke, dass die Länder ausreichen. Ich hab mir da in den letzten Monaten verschiedenste Programme, Tools, Shopsysteme angeschaut und die arbeiten sogut wie alle nur mit einer Ländertabelle, wo halt alle 239 Länder oder so drin stehen.
Ich denke auch das grobe Land sollte reichen für eine Systemsprache oder doch nicht? Ich sag mal "noch" ist mein System nicht wirklich groß und überschaubar, daher lasse ich mich gern eines besseren belehren.

Was deinen TIPP für die Alias Bezeichnungen der Tabellen bei den Joins angeht: vielen Dank.. hat auf Anhieb geklappt.

Deine Notation für die Tabellennamen habe ich mir auchmal angeschaut.
Warum genau machst du es so und nicht anders? Gibts in Sachen Datenbanken bei den Tabellennamen irgendwas, was ich noch nicht weiß, was man beachten sollte? Oder ist es wegen der evtl. Geschwindigkeit?
Die selbe Frage stell ich gleich noch zu den Spaltenbezeichnungen... :)

Okay.. das reicht erstmal.

Gruß, Mario...

[King^Lully]

Deine Notation für die Tabellennamen habe ich mir auchmal angeschaut.
Warum genau machst du es so und nicht anders?

Einfacher Grund, ich habe so datenbankeindeutige Feldnamen, wenn ich also meinen SQL-Code schreibe, so kann ich bspw. JOINs aus dem Gedächtnis schreiben und kann grundsätzlich auf Tabellenaliase verzichten (die mag ich nicht). Und ja, diese datenbankeindeutigen Feldnamen werden natürlich auch als Variablennamen weiterverarbeitet, das ist praktisch. Ich hasse nichteindeutig benannte Entitäten.   ;)

Gibts in Sachen Datenbanken bei den Tabellennamen irgendwas, was ich noch nicht weiß, was man beachten sollte? Oder ist es wegen der evtl. Geschwindigkeit?

Kurze Namen beschleunigen die Ausführung des SQL-Codes minimal.   ;)

Die selbe Frage stell ich gleich noch zu den Spaltenbezeichnungen... :)

Dito.

Ach so, natürlich solltest Du bei Namen nie auf Kürze scharf sein, wie das _so_viele_ machen, die paar Sekunden, die man so spart sind schlecht angelegt, stundenlanges Debuggen wegen pflegeanfälliger SW kann die Folge sein.
Namen sind mehr als Schall und Rauch.

[GELight]

Na das ist doch mal eine super Aussage.
Dank dir nochmal für deine ausführlichen Anmerkungen.
Werde mir das alles schön durch den Kopf gehen lassen und mal schauen, ob oder was ich evtl. an meinem DB Design umstricken kann oder werde.

Gruß, Mario