Hello Sven,
natürlich lasse ich nicht alle Bewegungen anzeigen, sondern nur die relavanten. Aber die verstecken sich eben zwischen den 40.000.
Nachdem das Problem mit der oberen Schranke sich geklärt hatte (mysql_num_rows() ist dann eben kliener als $limit) bleibt nur noch die Frage nach dem Unterschied zwischen
Select count(ID)from table where...;
Select count(*)from table where...;
wobei ID hier der Primärschlüssel ist. Es könnte acuh jedes andere Feld benutz werden. Ich will ja aber gar kein Resultset, sondern nur das Zählergebnis für die Filterbedingung. Und dafür möchte ich MySQL eben so wenig wie möglich arbeiten lassen.
Allerdings: Auch für diese Gesamtzahl gilt natürlich, dass sie im Moment der Abfrage schon wieder veraltet ist und nachfolgende neue Datensätze nicht anzeigt.
Ja, das kann man durch einen neuen Blätterversuch dann eben feststellen. Bei Sortierung "Timestamp" sind die neuesten Sätze ja sowieso immer am Ende. Ist nur blöd, wenn dann zwischendurch welche gelöscht werden. Dafür registriere ich bei Nutzung einer von der ID abweichenden Sortierung einen Aufsetzpunkt (where $intro > $checkpoint) und setze $offset auf 0 zurück. Diese Thematik hatten wir schon einmal. $intro besteht aus dem Sortier-Feld und der autoincrement-ID. Auch Timestamp ist bei 30 Bewegungen pro Sekunde ja leider nicht mehr unär.
So langsam bekomme ich da polymorphe Strukturen, sodass meine Funktionen allgemeinverwendbar werden.
Bleibt noch mein Problem, ob und wie man der Satzbeschreibung von MySQL eigene Kriterien hinterlegen könnte. Aber das Extra-Feld ist wohl nicht für den DB-Entwickler selber nutzbar. Das wäre nämlich klasse. Wie könnte man denn bei Version 3.23.55-max sonst die Relationen vermerken.
Ich behelfe mir im Moment über den Feldnamen. "ID_ADRESSE" bedeutet dann eben eine Relation zur Tabelle ADRESSE, wobei man ja leider nicht weiß, welcher Art sie ist (1:1, 1:n, n:1) und ob refenzielle Integrität gewahrt bleiben muss.
Schönen Sonntag noch
Tom