Tach!
Auch wenn ich dann ja spätestens beim Löschen eine zweite identische SELECT-Abfrage einbaue und hier dann am Ende eine Zwischenspeicherung in einem Array doch sauberer/performanter wäre, als ein zweites Select einzusetzen? Ich meine praktisch wird das wahrscheinlich vernachlässigbar sein, zumal wir von ca. 100 Datensätzen (Benutzern) sprechen, aber hinterfragen wollte ich das trotzdem :)
Bei 100 musst du dir keine großartigen Gedanken machen. Das geht selbst ohne Indexe flott. Ansonsten aber scheint es mir sinnvoller, die Abfrage als Subselect nochmal laufen zu lassen, als erst das Ergebnis zu einem anderen Server, zumindest aber zu einem anderen Prozess zu transportieren, es dort in eine neue Query umzuformen und so wieder zurückzusenden. Ein DBMS ist darauf ausgelegt und optimiert, mit Datenmengen umzugehen. Lass es das DBMS ausführen, das ist sein Job.
Die ID nicht als Primärschlüssel zu nehmen, favorisiere ich deshalb, weil die Statistiktabelle quasi alle Informationen enthalten soll und somit auch Standalone verwendbar ist (wenn das CMS mal nicht mehr ist oder gegen ein anderes ausgetauscht wird). Außerdem bekomme ich die Statistikwerte aus einer API wo der name das eindeutige Zuordnungskriterium ist. Im Hinblick auf eine saubere Normalisierung werde ich diesen Ansatz aber nochmal überdenken :)
Solange die Namen eindeutig sind, ist das kein Problem, diese zu verwenden. Aber wenn sich mal der Name ändert (wenn man das kann) sind auch die Statistikdaten weg, weil der Nutzer dann neu aussieht. Im ungünstigsten Fall hat sich ein neuer Nutzer mit dem alten freigewordenen Namen angemeldet. Da musst du mal alle möglichen Szenarien ermitteln und überlegen, was dann passiert.
Und man darf auch die Prinzipien der Normalisierung ignorieren, wenn man es begründen kann. Zum Beispiel kannst du den Namen als einfaches Datum ablegen und den Benutzer-PK auch als PK in der Statistiktabelle verwenden. Die API-Daten lassen sich dann immer noch über den Namen zuordnen (wenn die nicht auseinanderlaufen).
dedlfix.