Nächster Datensatz lesen

[Nebbiolo]

Hallo
Ich möchte bei einer SQL-Abfrage zB.
"SELECT * FROM gck WHERE gck_dat >='2022-01-31' ORDER BY gck_dat;
Diese Datensätze (funktioniert auch) aber noch zusätzlich einen weiteren lesen und den letzten Gruppenbruch zu erzwingen.
Gibt es so etwas wie zB. LIMIT 0,LAST+1
Viele Grüsse aus dem Süden
Nebbiolo

 

[dabadepdu]

Ich verstehe die Frage nicht. Gruppenbruch klingt nach PHP.
Wenn Du eindeutige Datensätze möchtest, musst Du statt * explizit die Felder die Du brauchst selectieren und gruppieren oder mit distinct bündeln.
Limit nimmt nur einen Parameter. "Last" ist was anderes als "einen weiteren", "Last +1" gibt es nicht und "Limit Last" wäre das gleiche wie Limit wegzulassen.
Was ist Deine Ausgabe derzeit und was soll sie sein? Poste einfach Beispieldaten.

 

[Georg V.]

Wie @dabadepdu schon schreibt nach dem letzten Datensatz einer Abfrage gibt es keinen weiteren Datensatz. Den letzten Zeilenumbruch (typischer Frontendbegriff) kann man nach der Ausleseloop direkt ausgeben (, wenn denn eine Ausgabe statt gefunden hat).

 

[Nebbiolo]

Danke für die Antworten!
Ich habe pro Tag mehrere Datensätze. Nun mache ich mit php eine Statistik wie viele Datensätze es pro Tag sind (natürlich mit Summen, Multiplikationen etc.). Dabei vergleiche ich die Daten (innerhalb des WHILE) - wenn sie nicht mehr gleich sind gebe ich die Total-Zeile aus. Das funktioniert eigentlich problemlos NUR der letzte Datensatz wird nicht ausgegeben ... dazu muss ich die ganze Ausgabeprozedur am Ende nochmals schreiben.
Natürlich kann ich das Datum um einen Tag erhöhen (WHERE) und dann selbst die WHILE-Schlaufe abbrechen ... aber so richtig schön finde ich das auch nicht. Wir löst ihr solche "Gruppenbrüche"?

 

[Georg V.]

Erste Frage, die mir sofort in den Kopf schiesst: Warum berechnest Du die Statistik nicht in der Datenbank? Zweite Frage: Du willst die neu dazu gekommen Zeilen (es können ja auch mehrere Zeilen sein) auslesen und diese mit in die Liste nehmen. Diskussionswürdiger Ansatz zu einem und zudem brauchst Du dann ein Merkmal wie einen Zeitstempel ode laufende Nummer, die bereits ausgelesen hast.

Edit Groß- und Kleinschreibung korrigiert

 

[Nebbiolo]

@Georg V.
Eine Statistik ist ja immer veraltet ;-)
Die Statistik möchte ich nicht direkt in der DB haben, denn ich habe viele Scripts die ich dann entsprechend anpassen müsste.
Meine Frage bleibt: wie löst ihr solche Gruppenbrüche?

 

[BerndB]

Limit nimmt nur einen Parameter.

Naja, LIIMIT hat 2 Parameter!

Die Syntax ist:

LIMIT offset, row_count LIMIT row_count OFFSET offset

 

[akretschmer]

Meine Frage bleibt: wie löst ihr solche Gruppenbrüche?

Du hast noch immer keine Beispieldaten geliefert, siehe #2

Dann liefere ich halt welche:

postgres=# select * from my_test ;
 id | salary | revised_salary | old_salary | leave | joining_date 
----+--------+----------------+------------+-------+--------------
 10 |   5000 |           4000 |       1000 |     5 | 2019-11-15
 10 |   6000 |           9000 |       2000 |     1 | 2019-11-16
 10 |   7000 |           3000 |       4400 |     2 | 2019-11-17
 20 |   8000 |           4000 |       6600 |     6 | 2019-11-15
 20 |   9000 |           9400 |       8800 |    10 | 2019-11-16
 20 |   2000 |           7800 |       9400 |    23 | 2019-11-17
 30 |   4400 |           6600 |       4200 |    44 | 2019-11-15
 30 |   1500 |           3600 |       4300 |    66 | 2019-11-16
 30 |   2000 |           2600 |       4500 |    77 | 2019-11-17
(9 rows)

postgres=# select id,joining_date,sum(salary) as total_salary,
sum(revised_salary) as total_revised_salary ,
sum(old_salary) as total_old_salary ,
sum(leave) as total_leave 
from my_test 
group by rollup ( id, joining_date)  order by 1, 2;
 id | joining_date | total_salary | total_revised_salary | total_old_salary | total_leave 
----+--------------+--------------+----------------------+------------------+-------------
 10 | 2019-11-15   |         5000 |                 4000 |             1000 |           5
 10 | 2019-11-16   |         6000 |                 9000 |             2000 |           1
 10 | 2019-11-17   |         7000 |                 3000 |             4400 |           2
 10 |              |        18000 |                16000 |             7400 |           8
 20 | 2019-11-15   |         8000 |                 4000 |             6600 |           6
 20 | 2019-11-16   |         9000 |                 9400 |             8800 |          10
 20 | 2019-11-17   |         2000 |                 7800 |             9400 |          23
 20 |              |        19000 |                21200 |            24800 |          39
 30 | 2019-11-15   |         4400 |                 6600 |             4200 |          44
 30 | 2019-11-16   |         1500 |                 3600 |             4300 |          66
 30 | 2019-11-17   |         2000 |                 2600 |             4500 |          77
 30 |              |         7900 |                12800 |            13000 |         187
    |              |        44900 |                50000 |            45200 |         234
(13 rows)

postgres=#

(von hier: How to Use Grouping Sets, Cube, and Rollup in PostgreSQL )


Ist es das, was Du suchst?

 

[dabadepdu]

Naja, LIIMIT hat 2 Parameter!

Die Syntax ist:

LIMIT offset, row_count LIMIT row_count OFFSET offset

Tatsächlich, habe ich nicht richtig nachgeschaut.
Diese Parameterbedeutung ergibt dann gemäß Fragestellung aber auch nicht mehr Sinn, also keinen?

 

[dabadepdu]

@Georg V.
Eine Statistik ist ja immer veraltet ;-)
Die Statistik möchte ich nicht direkt in der DB haben, denn ich habe viele Scripts die ich dann entsprechend anpassen müsste.
Meine Frage bleibt: wie löst ihr solche Gruppenbrüche?

Also da gibt es glaub ich ein Missverständnis. Eine Berechnung "in der Datenbank" bedeutet nicht, dass dort dann berechnete Daten rumliegen und langsam Rost ansetzen. Im Gegenteil, es sind nur aktuelle Abfragen, die genau das zurückliefern, was zum Zeitpunkt der Abfrage in der DB steht. Besser geht es nicht. Das ist ganz normale DB Handhabung.
Und noch zu Deiner "While Schleife": Ich würde behaupten, die musst Du nicht alle ändern, sondern die kannst Du alle entfernen. Statt dessen holst Du einfach aktuelle Abfrageergebnisse. Weniger Code (in PHP) und vor allem viel schneller. (Und später auch weniger zu verändern, wenn mal was geändert werden muss (am SQL))

 

[Nebbiolo]

Sooooo, ich habe eure Ratschläge angenommen und das ganze umgestellt- für mich als "alter" Cobol-Programmierer gar nicht so einfach.
Ist wirklich unglaublich was die Abfragen heute bieten, sum und group habe ich bis anhin gar nie verwendet.

Nun sieht der Code etwa so aus:
$sql="SELECT land, reg, datzeit, COUNT(*) FROM gck WHERE datzeit > '$datv' GROUP BY land, reg"
foreach ($mysqli->query($sql) as $row) {echo $row['COUNT(*)']; ...}
nicht nur schneller, sondern auch keine Problem mit dem Gruppenbruch (WHILE) mehr.

Ich möchte mich für Eure Geduld und Hilfe vielmal bedanken!

Viele Grüsse, Nebbiolo

 

[dabadepdu]

was die Abfragen heute bieten, sum und group habe ich bis anhin gar nie verwendet.

P.S.: Ich denke, in das Group gehört offiziell noch die Spalte datzeit rein. Sonst können fehlerhafte Ergebnisse angezeigt werden.
Du musst da bei mySQL/Maria besonders drauf achten. Alle Spalten, die nicht aggregiert ausgegeben werden, müssen im Group By genannt werden. Das ist eine Faustregel, es gibt auch andere Fälle, aber nicht, wenn Du damit gerade anfängst.