kannst du das posting mal zeigen? kann mich nich erinnern jemals was von 3 aufeinander folgenden selects gesagt zu haben ^^ ich hatte mal EINE select anweisung stück für stück entwickelt. bei jedem schritt kam was dazu und wurde eben erweitert. da hatte ich auch das mit den alias namen erklärt gehabt. dazu nochmal ein bsp:
nehmen wir 2 tabellen, die beide eine spalte ID haben (wie selten ^^). jetzt verknüpfen wir die eben in der sql anweisung (denke an den usernamen bspw) und das könnte so aussehen:
SELECT * FROM zeiten, user WHERE zeiten.User_ID = user.ID;
jetzt wird aus den (fürs beispiel gestutzten) tabellen zeiten (ID, User_ID) und user (ID, Name) die view (
ID, User_ID,
ID, Name) - du siehst: 2mal ID. wenn man jetzt aus irgendeinem grund eine der ID's braucht, muss man sich aufs glück verlassen, dass genau die richtige durchkommt, oder man hat pech gehabt. weil wenn er in $row['ID'] den wert aus zeiten.ID speichert und danach den aus user.ID wieder in $row['ID']... dat klappt so nich
solange man das nicht braucht, isses völlig bums. eine * suche ist schneller, da nicht noch spalten raussortiert werden müssen und daher zu bevorzugen, aber wenns nich geht, dann gehts nich. zum bsp hatte ich speziell das problem bei der produkt und tätigkeits tabelle. die benötigten spalten für die namen zu den id's hießen beide Bezeichnung - also musste ich mit aliasen arbeiten. um beim simplen bsp zu bleiben:
SELECT zeiten.ID AS zID, user.ID AS uID FROM zeiten, user WHERE zeiten.User_ID = user.ID;
nun haben wir explizit zugriff auf beide id's. einmal über $row['zID'] auf die aus zeiten und über $row['uID'] eben auf die aus user. und tabellen kann man auch mit aliasnamen versehen - spart schreibarbeit. wenn ich 10mal zeiten schreibe, dann spart mir ein z halt nerven xD
SELECT z.ID AS zID, u.ID AS uID FROM zeiten AS z, user AS u WHERE z.User_ID = u.ID;
ich kann im select-teil auf die tabellen-aliasse ausm from teil schon zugreifen (und bei where und order by... gehts auch). weil ich vorhin eine view erwähnte... lurzer ausflug in die theorie über datenbanken: im grunde wird alles als eine view dargestellt. lässt du dir enfach alles einer db-tabelle ausgeben, entspricht die view eben genau dieser tabelle. mit solchen "join-verbünden" hingegen verbindet man db-tabellen dann entspricht die view eben einem gewissen mischmasch. entweder alles zusammen oder nur teils teils. es gibt da innerjoins und outer joins, aber so recht hab ich das selber auch noch ned durchstiegen ^^ es geht zum bsp auch sowas:
SELECT * FROM bla WHERE SELECT * FROM blubb...; das wäre auch eine join-variante. könnte der outerjoin sein.
aber gut, wie gesagt, so wichtig isses nicht. aber der grundgedanke ist eben, mit abfragen baut man sich eigene spezielle tabellen, die einen gewissen blickwinkel, eben eine view auf die db darstellen. und um eindeutige spalten namen zu erhalten, muss man eben teils mit alias namen arbeiten. das doofe ist eben, braucht man nur EINEN wert mit aliasnamen, muss man alle anderen auch angeben :/ also nicht zwingend mit alias, aber eben ein * wert as w oder so geht halt nich ^^ bei mir reicht halt diese angegebene sql anweisung aus. man kann es auch aufsplitten. zum bsp erst macht man ein select für die zeiten und arbeitet das ab. und beim abarbeiten macht man bei jedem schleifendurchlauf eine weitere anbfrage um das projekt dazu zu bekommen. eine um den usernamen zu bekommen und weitere um die anderen id's zu ersetzen. aber du kannst dir vorstellen, die db raucht dann etwas ^^
das ist kein problem beim 1mann betrieb, aber wenn das dann wirklich mal zum einsatz kommt, belastet das die db eben unnötig. daher immer versuchen das alles zusammen zufassen. das erstellen der verzweigten view mag zwar 3 4 mal länger dauern wie die simple abfrage der zeiten-tabelle, aber wenn man dann in schleifen und unterschleifen wieder und wieder neue anfragen stellt... da is man dann je nach datenvolumen das zusammengesucht wird plötzlich 10mal schneller. zudem wird bei einer anfrage ein konsistenter zustand präsentiert. also der sucht alles zusammen, so wie es zum abfragezeitpunkt in der db war. wenn du jetzt lauter einzel selects hast, dann kann es im mehrnutzer betrieb durchaus vorkommen, das einer was ändert, während du deine schleife abarbeitest und plötzlich kommen komische ergebnisse zustande (inkonsistenzen eben).
wie es scheint, war mein studium nich völlig umsonst >< is noch ganz gut was hängen geblieben xD
.
Jedenfalls hattest du in der ursprünglichen Zeile bei den letzten drei WHERE Dingern p, und jetzt auf einmal ist das alles pr aber du meinst, es hätte nur einen Fehler gegeben?!
), aber er funktioniert nach meinen Anpassungen einwandfrei. 
Das glaube ich nicht ... da würde er ja so einen Käse speichern:
