MySQL Datensatzzählung mit COUNT(*)

[Melvin Cowznofski]

Hallo,

ich stehe gerade etwas verwundert vor dem Ergebnis einer Datenbankabfrage:

In einer MySQL Datenbank habe ich die 1199 häufigsten deutschen Familiennamen gespeichert. Es sind _garantiert_ 1199 unique, mit der id nach Häufigkeit geordnete Datensätze. Die id 1 hat den Namen "Müller", die id 1199 den Namen "Böck". Das kann ich mit einem SELECT f.familienname WHERE id = ... auch überprüfen. Den Beweis, dass es auch wirklich _exakt_ 1199 Datensätze sind, liefert zB. das leere Ergebnis bei SELECT f.familienname WHERE id = 1200.

Wenn ich MySQL nun einfach alle Datensätze zählen lassen möchte, dann mache ich das (so wie einst hier von dedlfix gelernt) mit einem SELECT COUNT(*), also SELECT COUNT(*) FROM familiennamen.

Das Ergebnis ist aber nicht wie erwartet 1199, sondern 1182, also um 17 zu wenig. Wieso werden mir 17 Datensätze unterschlagen? [*) Ergebnis mit XAMPP und Ausgabe via localhost]

Für eine gestaffelte Ausgabe von Datensätzen wie zB. 10 pro Anzeigeseite muss ich die _exakte_ Gesamtanzahl wissen, um auch entsprechend korrekte Links zur letzten Seite platzieren zu können.

Ich hoffe, mir kann weitergeholfen werden!

Mit lieben Grüßen

Melvin Cowznofski

[Tobias Hahner]

Hallihallo!

Hast Du vielleicht zwischendurch mal einzelne Datensätze gelöscht?

Beste Grüsse,
    Tobias Hahner

[Melvin Cowznofski]

Hallo Tobias!

Hast Du vielleicht zwischendurch mal einzelne Datensätze gelöscht?

Ganz sicher nicht!

So kamen die Namen in die Datenbank: Ich habe mir zuerst auf dieser Seite die 1199 häufigsten Familiennamen kopiert und in Excel eingefügt. Dort standen dann die Namen von den Nummern getrennt in einer eignen Spalte.

Diese Spalte wurde wieder kopiert und in notepadd++ in eine leere, neue Datei eingefügt. Mit der Ersetzen-Funktion habe ich dann die ae, ue und oe in ä, ü und ö umgewandelt sowie jedes \n in ein ',' umgewandelt. Nachdem der erste und letzte Datensatz, was Anführungszeichen und Beistrich betrifft, noch korrigiert worden sind, ist das ganze dann zum Inhalt eines Arrays einer php Ressource geworden: $familiennamen = array ('Müller','Schmidt','Schneider','Fischer', usw.)

Und mittels PDO landeten die Namen in einer frisch erstellten MySQL Tabelle. Seither wurde nichts hinzugefügt und nichts gelöscht.

Habe jetzt noch einen weiteren Test gemacht und mir _alle_ Familiennamen samt id in einer Tabelle ausgeben lassen. Das sind wie erwartet 1199 Namen. Das $anzahl = $query->rowcount(); dieser Abfrage liefert mir (bei der selben Ausgabe!) leider ebenfalls nur 1182 Datensätze. Ich verstehe das einfach nicht...

Mit lieben Grüßen

Melvin Cowznofski

[Steffen]

Hi,

mach mal folgendes

  
select id+1 as x from deine_tabelle  
  where x not in (select id from deine_tabelle)  

Das sollte Dir die fehlenden IDs ausgeben.

Grüße

• Steffen

[Helmut]

Hallo

Mit der Ersetzen-Funktion habe ich dann die ae, ue und oe in ä, ü und ö umgewandelt sowie jedes \n in ein ',' umgewandelt. Nachdem der erste und letzte Datensatz, was Anführungszeichen und Beistrich betrifft, noch korrigiert worden sind, ist das ganze dann zum Inhalt eines Arrays einer php Ressource geworden: $familiennamen = array ('Müller','Schmidt','Schneider','Fischer', usw.)

Das haut aber m.E. dann nicht hin, es gibt ja sowohl Müller als auch Mueller - der dann auch zu Müller wird wenn du ue usw. ersetzt.

Gruß Helmut

[Melvin Cowznofski]

Hallo Tobias,

habe jetzt einen weiteren Test gemacht, mir nochmals _alle_ Datensätze ausgeben lassen und mir "Alarm" geben lassen, wenn die id, die ausgegeben wird, nicht der Zahl entspricht, die erwartet wird. Und siehe da ... da fehlt wirklch was. Die id-Nummern 107, 111, 358, 433, 454, 494, 532, 592, 615, 719, 914, 964, 984, 1039, 1077, 1170 und 1196 bzw. fehlen. Und somit natürlich auch die ursprünglich dazu gehörenden Namen.

OK, somit ändert sich jetzt die Fragesetellung. Wieso nur 1182 Datensätze gezählt werden, ist somit klar. Die Frage lautet nun: Was kann der Grund dafür sein, dass 17 von 1199 Fällen fehlen? Ein INSERT muss ja gemacht worden sein, sonst wären die id-Nummern ja durchgehend. Komisch...

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

OK, somit ändert sich jetzt die Fragesetellung. Wieso nur 1182 Datensätze gezählt werden, ist somit klar. Die Frage lautet nun: Was kann der Grund dafür sein, dass 17 von 1199 Fällen fehlen? Ein INSERT muss ja gemacht worden sein, sonst wären die id-Nummern ja durchgehend. Komisch...

Das ist im nachhinein nicht mehr feststellbar. Vielleicht hast du damals Insert-Fehler übersehen. Du kannst nur herausfinden, welche Datensätze fehlen und mit denen den Import wiederholen, diesmal aber genauer aufpassen.

dedlfix.

[dedlfix]

Tach!

In einer MySQL Datenbank habe ich die 1199 häufigsten deutschen Familiennamen gespeichert. Es sind _garantiert_ 1199 unique, mit der id nach Häufigkeit geordnete Datensätze. Die id 1 hat den Namen "Müller", die id 1199 den Namen "Böck". Das kann ich mit einem SELECT f.familienname WHERE id = ... auch überprüfen. Den Beweis, dass es auch wirklich _exakt_ 1199 Datensätze sind, liefert zB. das leere Ergebnis bei SELECT f.familienname WHERE id = 1200.

Nein, das hat keine Beweiskraft. Das sagt nur, dass es keinen Datensatz mit der ID 1200 gibt. Es sagt nicht aus, wieviele andere existieren.

Wenn ich MySQL nun einfach alle Datensätze zählen lassen möchte, dann mache ich das (so wie einst hier von dedlfix gelernt) mit einem SELECT COUNT(*), also SELECT COUNT(*) FROM familiennamen.

Und ich wüsste auch nicht, warum MySQL da falsch zählen sollte.

Für eine gestaffelte Ausgabe von Datensätzen wie zB. 10 pro Anzeigeseite muss ich die _exakte_ Gesamtanzahl wissen, um auch entsprechend korrekte Links zur letzten Seite platzieren zu können.

Da nimmt man aber nicht eine gleiche zweite Abfrage mit COUNT() sondern SELECT SQL_CALC_FOUND_ROWS ... in der ersten und dann eine zweite mit SELECT FOUND_ROWS();

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Ich habe jetzt eine weitere Tabelle erstellt und mit der selben, in der Zwischenzeit nicht veränderten php Ressource, in dem sich das Array mit den 1199 Namen befindet, die Daten zur DB gesendet.

In dieser neuen DB zählt er jetzt tatsächlich 1199 Datensätze.

Nun stellt sich die Frage, wieso das beim ersten Mal nicht geklappt hat. Es ist so, dass ich ein meinem alten, langsamen Laptop einen USB-Stick stecken habe, auf dem sich XAMPP und die Datenbank befindet. Ich dachte zuerst, vielleicht sei das System "zu langsam" und kommt beim Speichern der Datensätze nicht mit, deshalb fehlen ein paar. Aber das ist natürlich Blödsinn, weil selbst dann gäbe es ja bei den id-Nummern keine Löcher sondern sie wären von 1 weg durchgehend nummeriert.

Ich _weiss_ doch, dass ich weder in phpMyAdmin noch in meiner php Ressource _je_ ein DELETE drinnen hatte heute. Also entweder gab es in den 14 Fällen nie ein INSERT - dann stellt sich die Frage, wieso die id-Nummern nicht durchgehend sind. Oder es gab ein INSERT, dann stellt sich die Frage, wieso 14 von 1099 Datensätzen plötzlich verschwinden.

Das ist im nachhinein nicht mehr feststellbar. Vielleicht hast du damals Insert-Fehler übersehen.

Das habe ich alles innerhalb der letzten Stunde gemacht. Ich werde es wohl trotzdem nie erfahren, was da passiert ist. =(

Da nimmt man aber nicht eine gleiche zweite Abfrage mit COUNT() sondern SELECT SQL_CALC_FOUND_ROWS ... in der ersten und dann eine zweite mit SELECT FOUND_ROWS();

Du hast Recht, 2 Abfragen sind umständlich. Eigentlich brauche ich ja nur die 2 Schritte umkehren. Zuerst mit _einer_ Abfrage die Daten holen, dann mit dem $anzahl = $query->rowcount() feststellen, wie viele Datensätze vorhanden sind und entsprechende Navigationslinks berechnen und setzen.

SQL_CALC_FOUND_ROWS und SELECT FOUND_ROWS() sagt mir nichts, aber das brauche ich somit ja nicht mehr. Oder ist das eine bessere Alternative?

Mit lieben Grüßen

Melvin Cowznofski

[Melvin Cowznofski]

Hallo dedlfix,

Du hast Recht, 2 Abfragen sind umständlich. Eigentlich brauche ich ja nur die 2 Schritte umkehren. Zuerst mit _einer_ Abfrage die Daten holen, dann mit dem $anzahl = $query->rowcount() feststellen, wie viele Datensätze vorhanden sind und entsprechende Navigationslinks berechnen und setzen.

ich habe mir das jetzt nochmal durch den Kopf gehen lassen. Nein, ich _muss_ zuerst wissen, wie viele Datensätze _insgesamt_ für ein entsprechendes SELECT zu finden sind und _dann erst_ hole ich mir die Daten von den paar Datensätzen ab, die auf einer Seite ausgegeben werden sollen.

Kommen also doch Deine 2 Funktioenn ins Spiel?!

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Du hast Recht, 2 Abfragen sind umständlich. Eigentlich brauche ich ja nur die 2 Schritte umkehren. Zuerst mit _einer_ Abfrage die Daten holen, dann mit dem $anzahl = $query->rowcount() feststellen, wie viele Datensätze vorhanden sind und entsprechende Navigationslinks berechnen und setzen.

Nein, damit bekommst du nur die Anzahl der Datensätze in der Ergebnismenge. Du brauchst auch noch die Gesamtanzahl der gleichen Menge, aber ohne LIMIT.

ich habe mir das jetzt nochmal durch den Kopf gehen lassen. Nein, ich _muss_ zuerst wissen, wie viele Datensätze _insgesamt_ für ein entsprechendes SELECT zu finden sind und _dann erst_ hole ich mir die Daten von den paar Datensätzen ab, die auf einer Seite ausgegeben werden sollen.

Jein, die Reihenfolge ist nicht weiter relevant. Es findet ja alles im selben Script statt und da kannst du nach Bedarf zwischenspeichern und später zugreifen.

Kommen also doch Deine 2 Funktioenn ins Spiel?!

Die machen es etwas einfacher. SQL_CALC_FOUND_ROWS berechnet nebenbei die Anzahl der Datensätze, die ohne eine LIMIT-Klausel in der Ergebnismenge landen würde. Die ermittelte Anzahl musst du dann nur noch mit einem einfachen SELECT FOUND_ROWS() abfragen. Das spart, die Query nochmal vollständig aber nur mit COUNT(*) und ohne LIMIT abzusetzen, sowie eine erneute Zählung auf dem Server.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix,

aaaahhhh .... da habe ich was gefunden!

Also statt Verbindung zur DB herstellen, alles zählen lassen, Verbindung schließen, Verbindung herstellen, Daten abholen und Verbindung schließen ... ist es schneller und einfacher das Daten abholen und Gesamtdaten-Zählenlassen, in _einem_ Durchgang zu machen.

Mit PDO habe ich das jetzt getestet. Es würde funktionieren: (hier nur der relevante Teil aus dem TRY-Block)

  
$nur_5_ausgaben = 'SELECT SQL_CALC_FOUND_ROWS f.id, f.familienname FROM familiennamen AS f ORDER BY f.id ASC LIMIT 5';  
$test           = 'SELECT FOUND_ROWS();';  
$query          = $db -> query($nur_5_ausgeben);  
$rows           = $query -> fetchAll(PDO::FETCH_ASSOC);  
$query          = $db -> query($test);  
$gesamtanzahl   = $query -> fetchColumn();

Ist das so wie von Dir gemeint?

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Ist das so wie von Dir gemeint?

Ja. Ein Semikolon ist zu viel (in der zweiten Query) und etwas Fehlerbehandlung schadet nie.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix,

Ein Semikolon ist zu viel

selbstverständlich! Das dürfte ich schon wieder mit einem nicht geprüften Copy & paste geschafft haben.

und etwas Fehlerbehandlung schadet nie.

Was genau meinst Du damit jetzt?

Schön übrigens, dass ich heute wieder was lernen durfte. Ich hatte von dieser Syntax bisher keine Ahnung, werde das aber in Zukunft so verwenden. Also auch wenn das nicht das Ziel meiner Frage war ... danke für die Info!!

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

und etwas Fehlerbehandlung schadet nie.
Was genau meinst Du damit jetzt?

Die Kommunikation mit dem DBMS (und auch andere Aktionen) kann immer mit einer Fehlermeldung statt des erhofften Ergebnisses enden - aus den verschiedensten Gründen. Das teilen dir die verwendeten Funktionen über ihren Rückgabewert mit oder werfen eine Exception (muss man unter PHP meist erst explizit einschalten). Ein gutes Programm plant quasi schlechtes Wetter mit ein und verlässt sich nicht nur auf den Sonnenschein.

Man kann da so vorgehen: Im Handbuch schaut man zu den verwendeten Funktionen nach, was sie im Fehlerfall liefern. Das steht immer irgendwo in der Beschreibung. Mitunter steht auch drin, wann diese Situationen auftreten können. Nun sollte man sich Gedanken machen, was bei dem jeweiligen Fehler getan werden kann. Ignorieren? Reicht Logging? Muss man das Programm auf alternativem Wege fortsetzen? Kunden (w/s)ollen zum Beispiel kaufen. Sie mit Fehlermeldungen oder Programmabbrüchen abzuspeisen ist nicht zielführend. Wie nimmt man trotz defekter Datenbank ihre Bestellung entgegen? Jedenfalls schreibt man nun Code, der auswertet, ob ein Fehler aufgetreten ist und implementiert die jeweilige Behandlungsstrategie. Und ja, Fehlerbehandlung kann gern mal den Unfang eines Programmes stark vergrößern.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Jaja, das ist alles klar und bekannt. Die Frage war eigentlich dahingehend gerichtet, wieso Du das überhaupt geschrieben hast.

Mit PDO habe ich das jetzt getestet. Es würde funktionieren: (hier nur der relevante Teil aus dem TRY-Block)

Ich dachte, daraus geht eigentlich hervor, dass es einen TRY-CATCH Block gibt und ich solche Dinge sowieso beachte...

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Jaja, das ist alles klar und bekannt. Die Frage war eigentlich dahingehend gerichtet, wieso Du das überhaupt geschrieben hast.

Mit PDO habe ich das jetzt getestet. Es würde funktionieren: (hier nur der relevante Teil aus dem TRY-Block)
Ich dachte, daraus geht eigentlich hervor, dass es einen TRY-CATCH Block gibt und ich solche Dinge sowieso beachte...

Das hatte ich überlesen und alles ist gut.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Da nimmt man aber nicht eine gleiche zweite Abfrage mit COUNT() sondern SELECT SQL_CALC_FOUND_ROWS ... in der ersten und dann eine zweite mit SELECT FOUND_ROWS();

Jetzt wollte ich das schon zu meinem neuen Standard machen, komme aber jetzt drauf, dass mir das nicht hilft:

Bei der seitenweisen Ausgabe von Datenbank Suchergebnissen wie zB. 10 Datensätzen pro Seite übergebe ich die Seitennummer per GET: www.example.com/results.php?page=3

Bisher habe ich zuallererst mit einem SELECT COUNT(*) alle Suchergebnisse gezählt und errechnet, wie viele Seiten das sind. Wurde für "page" _keine_ Seite übergeben, etwas anderes als Ziffern oder eine Seitenzahl, die es für das Ergebnis nicht geben kann, wird automatisch "page=1" ausgegeben.

Mit einem zweiten SELECT habe ich dann die eigentlichen Daten abgeholt, nämlich genau jene 10 (oder weniger, wenn es die letzten gefundenen Daten sind), die gerade ausgegeben werden.

Die Überprüfung der übergebenen Seitennummer kann ich mit SELECT SQL_CALC_FOUND_ROWS und SELECT FOUND_ROWS() aber nicht machen, weil sich da die Katze in den Schwanz beißt, da im SELECT ja schon mit LIMIT festgelegt wird, welche 10 Datensätze geholt werden.

Ich kann also entweder nur eine fehlende oder Nicht-Ziffern-Übergabe abfangen und mit Deinem Vorschlag arbeiten, oder ich möchte auch noch zu hohe Seitenanzahlen, die es gar nicht geben kann, abfangen, dann _muss_ ich zuerst zählen, um zu wissen, was die höchstmögliche Zahl nach dem LIMIT für die Ausgabe der Datensätze ist. Wie sonst soll es sonst möglich sein, bei zB. 30 betroffenen Datensätzen, wo es bei einer Ausgabe von 10 pro Seite nur 3 Seiten geben kann, ein "page=5" abzufangen und automatisch zu einem "page=1" werden zu lassen?

Bitte korrigiere mich, wenn ich falsch liege!

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Bei der seitenweisen Ausgabe von Datenbank Suchergebnissen wie zB. 10 Datensätzen pro Seite übergebe ich die Seitennummer per GET: www.example.com/results.php?page=3
Bisher habe ich zuallererst mit einem SELECT COUNT(*) alle Suchergebnisse gezählt und errechnet, wie viele Seiten das sind.

Warum musst du dazu die Gesamtanzahl der Datensätze wissen? Welche Datensätze in der Ausgabe sein sollen, errechnet sich aus der gewünschten Seite und der Zahl der Datensätze pro Seite. Die Gesamtzahl braucht man erst für den Pager.

Die Überprüfung der übergebenen Seitennummer kann ich mit SELECT SQL_CALC_FOUND_ROWS und SELECT FOUND_ROWS() aber nicht machen, weil sich da die Katze in den Schwanz beißt, da im SELECT ja schon mit LIMIT festgelegt wird, welche 10 Datensätze geholt werden.

Was willst du da noch mehr als nötig überprüfen? Unsinnige Werte (negative Zahlen, Buchstaben) kann man ebenso, wie wenn nichts angegeben wurde, zu Seite 1 werden lassen. Werte größer als effektiv Seiten vorhanden sind, ergeben eine leere Ergebnismenge. Das ist nicht mein Problem, wenn der Anwender vom System nicht vorgesehene Änderungen vornimmt. Wenn er da Unsinn anstellt, betrifft mich das ebensowenig wie wenn er beispielsweise unsinnige oder nicht vorhandene Suchbegriffe verwendet. Hauptsache die Pager-Links arbeiten korrekt und es gibt keine Injection- oder andere Probleme für die Integrität des Datenbestands.

Wie sonst soll es sonst möglich sein, bei zB. 30 betroffenen Datensätzen, wo es bei einer Ausgabe von 10 pro Seite nur 3 Seiten geben kann, ein "page=5" abzufangen und automatisch zu einem "page=1" werden zu lassen?

Warum wird das dann zu Seite 1 und nicht zu Seite 3 oder auch in der Mitte oder anderswo dazwischen (bei mehr als 3)? Ich finde es genausowenig nützlich, nach mehr als der vorhandenen Seitenzahl zu fragen, wie dann irgendwas zu liefern.

Bitte korrigiere mich, wenn ich falsch liege!

Du liegst nicht falsch, machst dir aber aus meiner Sicht hier zu viel Arbeit mit dem Überprüfen der Werte. Garbage in, Garbage out. Ich muss nicht alles korrigieren, was der Anwender falsch macht.

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Das ist nicht mein Problem, wenn der Anwender vom System nicht vorgesehene Änderungen vornimmt. Wenn er da Unsinn anstellt, betrifft mich das ebensowenig wie wenn er beispielsweise unsinnige oder nicht vorhandene Suchbegriffe verwendet.

So gesehen stimmt das natürlich. Wenn der Anwender die URLs, die er durch die Links bekommt, nicht angreift, dann kann dieser "Fehler" eh nicht vorkommen. Nur, wenn er manuell die vorgesetzte URL verändert und die Zahl nach dem "page=" durch eine andere ersetzt, kann das eine Seitennummer, die zu hoch ist, ergeben.

Du liegst nicht falsch, machst dir aber aus meiner Sicht hier zu viel Arbeit mit dem Überprüfen der Werte. Garbage in, Garbage out. Ich muss nicht alles korrigieren, was der Anwender falsch macht.

Mir ist das einfach lieber, wenn bei unsinniger Seitennummer in der URL die ersten Datensätze ausgegeben werden statt gar keine. Logisch begründen kann ich diese Vorliebe nicht. Danke jedenfalls für die Info, dass das bei Deinem Lösungsweg technisch nicht möglich ist. (Unabhängig davon, ob das Abfangen von unmöglichen Seitenzahlen jetzt sinnig ist oder nicht...)

Mit lieben Grüßen

Melvin Cowznofski

[dedlfix]

Tach!

Mir ist das einfach lieber, wenn bei unsinniger Seitennummer in der URL die ersten Datensätze ausgegeben werden statt gar keine.

Programmierst du für dich oder für die Anwender? Es gibt auch in dem Fall eine leere Datenmenge, wenn der Suchbegriff des Anwenders nichts findet. Setzt du ihm dann ebenfalls einfach die erste Seite vor? Du hast also dafür schon eine "keine Daten gefunden"-Anzeige eingebaut. Nimm die doch auch für die anderen nichts findenden "Eingaben". Als (selbst denkender) Anwender mag ich es eher, wenn ich auf meinen Fehler hingewiesen werde und nicht stillschweigend was anderes vorgesetzt bekomme und dann erstmal annehme, alles ist gut. (Selbst denkend heißt nicht, dass ich ständig alles überprüfen möchte, was mir da als Antwort vorgesetzt wird.)

dedlfix.

[Melvin Cowznofski]

Hallo dedlfix!

Es gibt auch in dem Fall eine leere Datenmenge, wenn der Suchbegriff des Anwenders nichts findet. Setzt du ihm dann ebenfalls einfach die erste Seite vor?

Stimmt, das mache ich nicht.

Du hast also dafür schon eine "keine Daten gefunden"-Anzeige eingebaut.

Richtig.

Nimm die doch auch für die anderen nichts findenden "Eingaben".

Ich könnte sogar eine eigene Meldung für diesen Fall machen. Wenn sich nämlich _nach_ dem SELECT (nach Deiner Methode) herausstellt, dass die Seitenanzahl unsinnig war, bekommt der Anwender statt der ersten Seite überhaupt kein Ergebnis _plus_ den Hinweis, er soll die URL in Ruhe lassen, weil ich ihm sonst via Teletext und Morsezeichen sein Diskettenlaufwerk deaktiviere.

OK, Du hast mir mit Deinen Argumenten gezeigt, dass meine Sichtweise da wirklich suboptimal gewesen ist. Ich werde somit weitrehin den von Dir vorgeschlagenen Weg mit SELECT SQL_CALC_FOUND_ROWS  und SELECT FOUND_ROWS() gehen.

Vielen Dank für den Denkanstoß!

Mit lieben Grüßen

Melvin Cowznofski