Abfrage einer MySQL Datenbank

webdoktor

webdoktor

Angesehenes Mitglied
Hallo zusammen

Ich habe folgende Abfrage einer MySQL Datenbank:

CODE //Auslesen der Datenbank Benutzer und Austritt (Verknüpft)
$abfrage_mutation = "SELECT benutzer.* FROM benutzer INNER JOIN mutation ON benutzer.id = mutation.id_benutzer
WHERE name LIKE '%$_POST[name]%' and vorname LIKE '%$_POST[vorname]%' and mutation_abgeschlossen = 0 GROUP BY id ORDER BY mutation.id DESC";
$ergebnis_mutation = mysql_query($abfrage_mutation);
$anzahl_mutation = mysql_num_rows($ergebnis_mutation);


Das funktioniert alles super und ich kann mit
$row_mutation->name

Die Namen von der "Benutzer-Tabelle" schön anzeigen. Nun habe ich aber noch Werte in der "Mutation-Tabelle" welche ich auch
anzeigen möchte wie z.B. ein Datum. Wenn ich aber eingebe

$row_mutation->datum

zeigt er mir nichts an da er wohl Bezug auf die Datenbank "Benutzer" nimmt. Wie muss ich es eingeben, damit ich die Werte
der Tabelle "mutation" anzeigen kann?

Vielen Dank für eure Hilfe.
Marco
 
CODE $abfrage_mutation = "SELECT benutzer.*, mutation.* FROM benutzer INNER JOIN mutation ON benutzer.id = mutation.id_benutzer
    WHERE name LIKE '%$_POST[name]%' and vorname LIKE '%$_POST[vorname]%' and mutation_abgeschlossen = 0 GROUP BY id ORDER BY mutation.id DESC";
$ergebnis_mutation = mysql_query($abfrage_mutation);
$anzahl_mutation  = mysql_num_rows($ergebnis_mutation);


ich hoffe, dass ich dich richtig verstanden habe...einfach noch ein "mutation.*" in den SELECT-Teil.

Grüße
Oli
 
Hi Oliver

Danke für die prompte Antwort. Naja habe es vielleicht etwas kompliziert umschrieben :)
Leider geht es nicht nur noch mutation.* anzuhängen es erscheint eine Fehlermeldung:

CODE mysql_num_rows(): supplied argument is not a valid MySQL result resource in xxx on line 50


Hmm?
Danke für Deine Bemühungen.

Gruss Marco
 
QUOTE (webdoktor @ Fr 8.01.2010, 14:07)
CODE SELECT [...] WHERE [...] LIKE '%$_POST[name]%'




Das war zwar nicht deine Frage, Marco, aber:

Variablen (wie $_POST/$_GET etc.) solltest du vor der Verwendung in Datenbank-Abfragen IMMER erst validieren.
Ungefilterte Variablen bieten Angriffsfläche für SQL-Injections.
 
Ist für den Wert benutzer.id IMMER ein Vergleichswert in der Tabelle "mutation" vorhanden?
 
QUOTE (Heiko R @ Fr 8.01.2010, 13:29)Ist für den Wert benutzer.id IMMER ein Vergleichswert in der Tabelle "mutation" vorhanden?

Vermute ich mal aus der Abfrage:

[...] benutzer.id = mutation.id_benutzer [...]



Mich würde eher interessieren, um mysql_query sauber durch geht:

Also mal eine Fehlerbehandlung einbauen, wie diese bspw.:

CODE if ( !$result = mysql_query($sql) )
{
   exit(mysql_errno() . ' - ' . mysql_error());
}





QUOTE (webdoktor @ Fr 8.01.2010, 13:18)[...]

CODE mysql_num_rows(): supplied argument is not a valid MySQL result resource in xxx on line 50

[...]

Dein Fehler lässt nämlich vermuten, dass der mysql_query nicht richtig lief, ergo die Abfrage wohl nicht sauber gestellt wurde und auf einen Fehler lief.
 
QUOTE (Sascha Ahlers @ Fr 8.01.2010, 14:58)
QUOTE (Heiko R @ Fr 8.01.2010, 13:29)Ist für den Wert benutzer.id IMMER ein Vergleichswert in der Tabelle "mutation" vorhanden?

Vermute ich mal aus der Abfrage:

[...] benutzer.id = mutation.id_benutzer [...]


Ein INNER JOIN führt die Datensätze der linken und rechten Tabelle dann zusammen, wenn ALLE Kriterien erfüllt sind.
Daher meine Vermutung: Die Kriterien stimmen vielleicht einfach nicht.

Edit:
Bei einem weiteren Blick auf das Sql-Statement fällt auf, das das "group by"-Kriterium nicht eindeutig definiert ist.
Da das ursprünglich von Marco gepostete Statement (wenn auch fehlerhaft) Ergebnisse lieferte, das abgeänderte jetzt aber nicht mehr, wird es möglicherweise einfach daran liegen:
"GROUP BY id", es gibt aber das Feld "id" in beiden Tabellen, die (wenn ich die Abfrage richtig interpretiere) keine identischen Werte haben.
Also "GROUP BY benutzer.id" oder "GROUP BY mutation.id".
Allerdings... Wenn "benutzer.id" und auch mutation.id" (wovon ich ausgehe) die PRIMARY-Keys der jeweiligen Tabellen sind, wäre das GROUP BY überflüssig.
 
Hallo zusammen

Huiii langsam wird es mir zuuuuu komplex. Eigentlich möchte ich einfach noch auf Werte
zugreifen die in der Tabelle "mutation" liegen da ich dort ein datum habe welches ich
brauche.

ansonsten funktioniert alles einwandfrei.

gibt es da keine einfache für mich verständliche lösung :)

LG Marco
 
Abgesehen davon, dass man nur in ganz wenigen Fällen Abfragen mit "*" machen sollte:

SELECT benutzer.*, mutation.datum FROM benutzer LEFT JOIN mutation ON benutzer.id = mutation.id_benutzer
 
QUOTE (webdoktor @ Fr 8.01.2010, 14:21)[...] gibt es da keine einfache für mich verständliche lösung :) [...]

Welchen Fehler gibt den die Fehlerbehandlung zurück, die ich oben gepostet habe?

@bendecho Da fehlt die Hälfte:


CODE SELECT benutzer.*, mutation.datum FROM benutzer
INNER JOIN mutation ON benutzer.id = mutation.id_benutzer
WHERE
  benutzer.name LIKE '%$_POST[name]%' AND
  benutzer.vorname LIKE '%$_POST[vorname]%' AND
  benutzer.mutation_abgeschlossen = 0
GROUP BY benutzer.id
ORDER BY mutation.id DESC;



Oder gleich das JOIN weg, und back to the roots:


CODE SELECT benutzer.*, mutation.datum FROM benutzer, mutation
WHERE
  benutzer.id = mutation.id_benutzer AND
  benutzer.name LIKE '%$_POST[name]%' AND
  benutzer.vorname LIKE '%$_POST[vorname]%' AND
  benutzer.mutation_abgeschlossen = 0
GROUP BY benutzer.id
ORDER BY mutation.id DESC;



@Heiko R
Ist mir soweit wohl klar, nur wenn die Felder da sind, gibt er halt keine Rows zurück, würde aber dann auch bei mysql_num_rows ein Ergebnis von 0 liefern, und nicht auf einen Fehler laufen. Zur GROUP BY bei INNER JOINs kann ich nichts sagen, da ich INNER JOINs bei MySQL vermeide und nur sehr am Rande mal kurz mit zu tun hatte.

Oder arbeitet der JOIN-Optimierer von MySQL nun sauber? Hab ja nach 4.1 nicht wirklich intensive mit MySQL gearbeitet.
 
Wenn wir nun schon bei der Kosmetik angekommen sind:
-Keine Select *
biggrin.gif

-Das Group by sieht sehr abenteuerlich aus so. Da müssten entweder alle Spalten oder Aggregatsfunktionen dazu gehören
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben