2 fach Kreuzung lösen in einer Query

[staeblorette]

Hallo jungs,
Ich hab hier 3 tabellen
1. Tabelle:Beiträge: hat die felder BeitragsID Text Überschrift...
2.Tabelle:Views:hat die felder viewID UserID BeitragsID...
3.Tabelle:Ranting:mit RatingID BeitragsID UserID datum...
Um jetzt die Bewertung und die Views für einen Beitrag zu bekommen musste ich die 2 mal kreuzen. Dabei kam ziemliocher unfuhg heraus und ich musste viel rechnen und denken bis ichs hatte.



SELECT a.BeitragsID, a.Description, a.Header, a.Date, COUNT(DISTINCT b.date) as Views, SUM(c.Rating)/Count(c.BeitragsID) AS Rating
FROM aspnet_Beitrag AS a, aspnet_Views as b,aspnet_Rating AS c
WHERE a.Date >= @date AND b.BeitragsID = a.BeitragsID AND c.BeitragsID = b.BeitragsID
GROUP BY a.BeitragsID,a.Description, a.Header, a.Date
ORDER BY a.date


Das ganze funktioniert jetzt weil die datensätze die durch die kreuzung entstehen eine proportionale vervielfältigung von den eigentlichen rating-einträgen sind.


beispiel:
1 Beitrag, 5 views, 6 ratings
der rating-durchschnitt is 3
durch die doppelte kreuzung werden jeder der 5 views mit jedem der 6 ratings gekreuzt
raus kommen 30 datensätze
innerhalb von den 30 ergebnisdatensätzen steckt jedes wirkliche rating das abgegeben wurde genau 5 mal drin.


ABER: Was ist wenn ich jetzt nicht 6 ratings und 5 Views hab sonder 69954126 Views und 45698322 Ratings?????

Könnt dann mein Server zusammenbrechen....
und überhaupt...verbraucht es nicht zuviele ressourcen jedesmal eine abfrage auszuführen die alle spalten in miner tabelle zählt? Also wenn ich 13125 Beiträge hab und davon jeder irgendwie 51385 Views und 1062 Ratings..
Ich meine wird es dann nicht alles zuviel????

Vielen Dank schonmal im vorraus für die antworten..achja falls jemand ne besser lösung hat kann er sie gerne posten

Gruß
staeblorette

[Falk Prüfer]

Hallo staeblorette,

also für das was du willst wäre die Abfrage durchaus korrekt - wenn auch fachlich nicht ganz exakt
COUNT(DISTINCT b.date) as Views würde dir Views die zur exakt gleichen Zeit erfolgen (was ja theoretisch durchaus möglich ist) nur einmal zählen. Richtiger wäre hier wohl COUNT(DISTINCT b.viewID) as Views. Kann natürlich sein das dies explizit so gewolllt ist.
Ansonsten würde ich das was passiert wenn ... dem Serer sein Problem sein lassen. Bei vernünftiger Indizierung sollten auch 13125 Beiträge mit jeweils 51385 Views und 1062 Ratings kein Problem sein.

Wenn du dir jedoch schon Gedanken um die Performance und Datenmenge machst, würde ich hier einen ganz anderen Ansatz sehen und zwar im Datenmodell. Warum muß für jeden View ein DS gespeichert werden? Was ist hier die notwendige Eindeutigkeit? Nach meiner Auffassung reicht es pro BeitragsID EINEN DS anzulegen und jeweils pro View in diesem DS einen Counter hochzuzählen. Das reduziert die notwendige Datenmenge sehr viel mehr als eine optimierte Abfrage.
Das gleiche gilt für das Rating. Ist es wirklich notwendig zu speichern welcher User wann welches Rating zu welchem Beitrag abgegeben hat oder reicht hier als Eindeutigkeit vielleicht BeitragsID und Rating und für die Anzahl der gleichen Ratings wieder ein Counter?

Gruß Falk