nicht angemeldet
Moin!
Hallo Sven, kenne eigentlich kompetentere Antworten von Dir.
Willst du diesen Thread herunterbrechen auf eine "Frage der Kompetenz"? Scheint im anderen Zweig ja so zu sein.
Mein Beispiel fragt nur eine Zeile ab ?
Woher weisst du das ?
Die Id 223 kann 100.000 mal vorkommen wenn nicht unique, Richtig ?
Richtig, aber dagegen sprechen zwei Dinge:
1. Eine Spalte "ID" ist in aller Regel unique, ansonsten würde man sie nicht "ID" nennen.
2. Wenn du eine Non-unique-Spalte abfragen und tausende Ergebniszeilen erwarten würdest, würdest du sicher andere Dinge mit dem Ergebnis anstellen, als einfach nur auf "Anzahl der Spalten != 1" zu prüfen. Denn was anderes als das DB-Ergebnis wegwerfen tust du ja nicht, wenn du die Ressource-ID nicht abspeicherst, um dann darauf zuzugreifen.
Im Übrigen war das nur ein Beispiel, mach doch mal ein Counterscript
mit Statisken mit mysql_num_rows(), lächerlich so was.
Für die Wahl deines Beispiels bist du natürlich selbst verantwortlich. Wenn das Beispiel schlecht war: Wähle ein besseres.
Außerdem: Wenn ich Statistiken aus einer DB wissen will, in der hinreichend viele Datensätze sind (hinreichend bedeutet für mich durchaus ab 2 Stück, je nach Tagestemperatur), dann werde ich mit Sicherheit weder mysql_num_rows() noch mysql_affected_rows() verwenden, sondern mit SELECT, COUNT(), GROUP BY sowie diversen anderen Aggregatsfunktionen genau die Information performant (und mit Indexnutzung) von der Datenbank abfragen, die ich brauche. Ein simples "SELECT COUNT(*) FROM tabelle" ist von der Performance her jeglichem "SELECT spalte FROM tabelle" plus mysql_affected_rows() überlegen.
Wenn ich die Zahl der abgefragten Datensätze aus der DB wissen _und_ weiterverarbeiten will, werde ich mysql_num_rows() in Verbindung mit mysql_query() verwenden. Üblicherweise aber interessiert mich die Zahl der Datensätze absolut nicht, ich verwende einfach einen nach dem anderen, solange welche aus dem Zwischenpuffer kommen. Das bedeutet, dass bei wirklich großen Ergebnissätzen, bei denen die Anzahl zu wissen eine Rolle spielt, tatsächlich zwei Querys an die DB gehen: Einer zum Durchzählen, und ein mysql_unbuffered_query().
Also ich gehe mal davon aus auch du weisst nicht warum
man mysql_affected_rows nicht nehmen soll, obwohl es geht ?
Und sag jetzt nicht, weil es geschrieben steht...
Ich frage mich, woher du deine Annahmen hast. Sowohl die, dass mysql_affected_rows() böse sein soll, noch die, dass es nicht funktionieren soll.
ps. Erst denken dann kritisieren, sonst geht der
Schuss nach hinten loss.
Ich habe das kritisiert, gegen das du dich in deiner Antwort gar nicht gewendet hast. Nämlich die mangelnde Fehlerbehandlung. Und die etwas abstruse Argumentation hinsichtlich Performance.
Die Dokumentation von MySQL sagt jedenfalls: "Bei SELECT funktioniert mysql_affected_rows() wie mysql_num_rows()." Damit wäre dein Performanceargument hinfällig, weil: Wenn es gleich funktioniert, warum sollte das eine dann superschnell und das andere arschlahm sein?
Aber nur wenn man mysql_store_result() (der MySQL-API) benutzt, wird tatsächlich danach sofort die Anzahl der Ergebniszeilen zurückgegeben, ansonsten erhält man das Ergebnis erst nach Abfrage aller Ergebniszeilen mit mysql_use_result() (und dann hätte man auch einfach selbst mitzählen können).
Bevor du also irgendwelche explosivbeschleunigte Masseteilchen in unintendierte Richtungen losgehen siehst, solltest du sicher gehen, dass du nicht in der Flugbahn derselben stehst.
Oder kurz: Wer lesen kann, ist klar im Vorteil. Man muß aber auch wissen, wo. :)
- Sven Rautenberg