nicht angemeldet
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.
Ok, vielen Dank, dass du das nochmal so ausgeführt hast.
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.
Genau so ist es gewünscht. Ein Nutzer selbst kann zwar seinen Nutzernamen nicht ändern, sehr wohl aber die Admins. Und in diesem (Ausnahme-)Fall soll dann tatsächlich die Statistik zu dem bisherigen Namen nicht auf den neuen Namen übertragen werden. Wenn sich ein neuer Nutzer mit dem freigewordenen Namen anmeldet ist dies durchaus möglich, aber auch unproblematisch. Ich führe das jetzt mal nicht weiter aus - es sei denn, ich habe jetzt die Neugier von jmd. geweckt, um was für eine Statistik es hier geht (davon gehe ich jetzt aber erstmal nicht aus).
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).
Ehrlich gesagt, habe ich die Normalisierung hier erstmal der Funktion untergeordnet. Ich werde das aber nun wirklich (ganz ehrlich) auch nochmal mit in die Umsetzung mit einbeziehen. Ich erkenne hier auch durchaus Vorteile.
Ich denke, ich bin nun auf einem guten Weg bzw. habe schonmal einen guten Plan in der Hand mit dem ich mich jetzt auf dem Weg machen kann*. Vielen lieben Dank dafür dedlfix.
FG
Alex
*sollte ich mich unterwegs doch nochmal verlaufen, werde ich mich sicher nochmal melden :)