nicht angemeldet
moin,
Also ein Feld "userName" und eines Namens "titelUrl"
beides ein wenig unglücklich in meinen augen, ich würde hier drei tabellen erwarten, eine für die user, eine für die titel und eben eine beziehungstabelle. ändert sich in deinem falle zum beispiel der username, müssen sich die schlüssel mit verändern. das ist bei systemen, wo es nur um die auswertung drauf ankommt (OLAP) nicht so relevant. fragt sich, ob dein system nur der auswertung dient, oder doch eher um eine OLTP datenank.
Man sieht also schon, das das kein Query im Sekundenbereich werden wird
50 millionen einträge ist schon eine etwas größere sache, nichts was in der praxis nicht vorkommt. aber wenn es hier um den einsatz in einem im geschäftlichen umfeld geht, dann stellt sich auch die frage geeigneter hardware und software. die frage ist auch, wieviele user in der tabelle enthalten sind. wenn es zum beispiel 100.000 verschiedene user sind, dann würdest du eine ergebnismenge von 100.000 * 99.999 bekommen, das geht in die milliarden.
SELECT
COUNT(b.userName) as c
FROM userTitel a
INNER JOIN userTitel b ON b.titelUrl = a.titelUrl
WHERE a.userName != b.userName
GROUP BY b.userName
HAVING c > 20;
du hast da einen logische fehler, du gruppierst nur über eine der user spalten, sprich du bekommst pro user nur einen datensatz zurück geliefert, wo eben die matches der titel aller anderen user aufsummiert werden. wenn ich dich richtig verstanden habe, willst du aber eine auswertung von jedem user zu jeden anderen user. auch der weg über die gruppierung scheint mir ungünstig zu sein. zum weiteren würden datensätze wegfallen, zum beispiel wenn ein user einen sehr aussergewöhnlichen geschmack hat und demzufolge keine gemeinsamkeit in den titel mit anderen users, dann würde der user einfach wegfalllen. hier kommt wieder mein merksatz zum tragen: JOINS sind böse ;-) noch ein anderer hinweis, benutze COUNT(\*), wenn es eh keine NULL werte gibt.
der weg zu einer guten abfrage ist eigentlich immer der gleiche. erst einmal die ergebnismenge sicherzustellen und sich dann gedanken über die projektion zu machen. dafür wäre die aufteilung in drei tabellen günstig, die ich am anfang angesprochen habe. dann würde man einen selfjoin machen, um die gewünschte ergebnismenge bekommen, in der projektion würden dann korrelierte unterabfragen zum einsatz kommen. aber wie gesagt, wenn du diese matrix für alle user mit allen usern machen willst, das geht in die milliarden. fragt sich wofür du solch eine ergebnismenge brauchst.
Ilja