Bewertungen von Beiträgen

Hallo allerseits!

Ich bin mir nicht sicher, ob das die richtige Kategorie für das Thema ist. Jeder kennt das Bewertungssystem mit den Sternchen, üblicherweise von einem bis fünf, wobei fünf Sternchen die höchste Bewertung darstellt. Dazu habe ich zwei (bis vier) Fragen.

Die eine betrifft die übliche Durchführung. Man speichert wohl üblicherweise die Anzahl an Bewertungen und die Gesamtsumme der Bewertungen und rechnet daraus das arithmetische Mittel aus. Möglicherweise per PHP. Aber MySQL soll so einfache Rechnungen auch ausführen können und außerdem noch schneller sein. Dazu ist meine Frage: Muß eine Rechenaufgabe, die MySQL ausführen soll, in einem lesend zugreifendem Query stehen oder kann man Formeln in eine Datenbankzelle schreiben? Falls man das so machen kann, wann würde die Rechnung dann ausgeführt?

Das kann man vielleicht schon als zwei Fragen zählen, aber meine erwähnte andere Frage ist allgemeinerer Natur und zwar folgende:
Wäre es nicht sinnvoller Bewertungen nach objektiven Kriterien durchzuführen? Nehmen wir zum besseren Verständnis Forumbeiträge als Beispiel. Man kann eine Bewertungsfunktion mit Sternchen einbauen, die von anderen Nutzern des Forums verwendet werden kann. Aber das kann ignoriert werden oder jemand verwendet die Funktion für einen Beitrag mehrfach (andernfalls müßte man auch noch für jeden einzelnen Beitrag und jeden einzelnen Nutzer mitzählen, ob die Funktion schon verwendet wurde oder nicht). Oft dürfte eine Rolle spielen, wer den Beitrag geschrieben hat. Aber guten Beitrag dürfte doch viel mehr auszeichnen, daß er zu mehr Antworten führt oder häufiger verlinkt wird. Ich halte es für besser, Bewertungen danach durchzuführen, welche Reaktionen (antworten und verlinken sind dafür konkrete Beispiele) ein Beitrag erzielt. Das Problem dabei ist: Wie bringe ich es fertig, eine an sich beliebige Anzahl von Antworten oder Verlinkungen auf fünf Sternchen gerecht zu verteilen?
Ranma

Ein CREATE PROCEDURE klingt erschreckend umständlich für mich. Man kann auch in PHP irgendwie Funktionen zur Laufzeit erzeugen. Mir ist nicht klar, wozu das überhaupt gut sein könnte.

Leider nur dem Namen nach, kenne ich einen tabellenorientierten Programmierstil. Ich stelle mir das so vor, daß man Funktionen in Datenbankzellen ablegt. Aber vielleicht habe ich das völlig falsch verstanden. Irgendwie müßte man dann schließlich der Datenbank noch erklären, daß es sich um auszuführenden Code und nicht nur um abzuspeichernden Text handelt.

Lohnt sich der Aufwand einen Knopf für einen Nutzer nur jeweils einmal klickbar zu machen? Es gibt natürlich verschiedene Arten der Umsetzung. Entweder beim Nutzer speichern, wo der schon geklickt hat, oder beim Beitrag speichern wer da geklickt hat oder ... . Aber falls nun der Beitrag beispielsweise danach noch editiert würde, müßte man den entsprechenden Wert doch wieder zurücksetzen? Nach meinem Empfinden nützt nämlich das schönste und komplizierteste Bewertungssystem nichts, wenn es am Ende nicht einigermaßen gerecht ist.

Vor allem so etwas wie für eine Antwort schon ein Sternchen, aber für mehr als fünfzehn bleibt es dann bei fünf, weil das das Maximum ist, das empfände ich schon als ungerecht. Andererseits wolltest du mit deinem Vorschlag vielleicht schon berücksichtigen, daß viele Antworten weniger wahrscheinlich sind als wenige Antworten?

Meiner Beobachtung nach, aber ich beobachte nur wenige Foren, sind viele Antworten zwischen nur zwei Teilnehmern ein starker Hinweis auf Gezanke. (In diesem Forum ist es allerdings ein Hinweis auf intensive Betreuung und das scheint mir eine große Ausnahme zu sein.) Gezanke will ich natürlich nicht belohnen. Vielleicht sollte ich nur berücksichtigen, von wievielen Leuten die Antworten stammen. Zuverlässig auseinanderhalten lassen sich natürlich nur die Registrierten. Die haben den weiteren Vorteil, daß man deren Anzahl kennt, so daß man mit Prozenten rechnen kann, wenn man für so eine Bewertung nur Registrierte berücksichtigt. Das setzt noch voraus, daß man kaum Karteileichen hat. Die zu identifizieren wäre damit schon wieder die nächste Herausforderung.
Ranma

Ich stelle mir das so vor, daß man Funktionen in Datenbankzellen ablegt. Aber vielleicht habe ich das völlig falsch verstanden. Irgendwie müßte man dann schließlich der Datenbank noch erklären, daß es sich um auszuführenden Code und nicht nur um abzuspeichernden Text handelt.

Was möchtest du denn ausführen?

Es gibt natürlich verschiedene Arten der Umsetzung. Entweder beim Nutzer speichern, wo der schon geklickt hat, oder beim Beitrag speichern wer da geklickt hat oder ... .

... in einer eigenen Tabelle, wobei jeder Klick einen eigenen Eintrag bekommt.

Vor allem so etwas wie für eine Antwort schon ein Sternchen, aber für mehr als fünfzehn bleibt es dann bei fünf, weil das das Maximum ist, das empfände ich schon als ungerecht. Andererseits wolltest du mit deinem Vorschlag vielleicht schon berücksichtigen, daß viele Antworten weniger wahrscheinlich sind als wenige Antworten?

Ja. Das ganze war aber auch nur ein Beispiel. Man muss sich halt überlegen, wie die Verteilung der Zahlen sein könnte.

Zum ausprobieren bin ich erstmal damit zufrieden, die Berechnung eines arithmetischen Mittels von MySQL ausführen zu lassen.

Dazu gibt es entsprechende Funktionen, die man in den Queries verwenden kann:

https://dev.mysql.com/doc/refman/5.0/en/group-by-functions.html

Eine eigene Tabelle, um zu speichern was angeklickt wurde? Aber die müßte sich dann sowieso Daten aus der Tabelle der registrierten Nutzer und auch aus der Tabelle der Beiträge holen?

Mann kann in einer Abfrage Tabellen mittels JOIN verknüpfen.

Ist das vielleicht sogar der falsche Ansatz, daß ich zusammenhängende Daten möglichst in der selben Tabelle unterzubringen versuche?

Ja, es kann durchaus von Vorteil sein, Datenbanktabellen aufzuteilen, genauer gesagt zu normalisieren:

https://de.wikipedia.org/wiki/Normalisierung_%28Datenbank%29

Im Einzelfall können aus Performance-Gründen aber auch Denormalisierungen, d.h. redundante Einträge, angebracht sein.

Also ich sehe mir stored routines an. Bis jetzt habe ich zwar noch nicht so richtig verstanden, wie das funktioniert, aber ich habe schonmal eine kleine Pro-und-Kontra-Liste:

Pro 1: rechnen in MySQL soll schneller sein als in PHP.

Pro 2: dazu soll es auch noch die Sicherheit erhöhen.


Kontra 1: stored routines brauchen Zugriff auf die Tabelle PROC, die bei der Installation von MySQL angelegt wird. Damit hängt die Sicherheit aus Pro 2 von den gewährten Rechten ab.

Kontra 2: nicht nur die Sicherheit, sondern auch ob überhaupt die Möglichkeit besteht, stored routines zu verwenden, hängt davon ab, was der Hoster erlaubt.

Kontra 3: Man weiß ja nicht, wo der Hoster wiederum sein MySQL installiert hat. Eventuell besteht da nochmal ein Server-Client-Verhältnis, das den Geschwindigkeitsvorteil aus Pro 1 wieder zunichte macht.

Kontra 4: Debugging soll ungleich schwieriger sein als bei einem PHP-Programm.

Kontra 5: Bei einer Aktualisierung von MySQL muß man möglicherweise einige der Routinen umschreiben, während die Abwärtskompatibilität des Flickenteppichs PHP ihresgleichen sucht.


Es könnte also sein, daß sich der Aufwand garnicht lohnt. Ist es üblich, daß Hoster Zugriff auf PROC gewähren? Wird darauf in Angebotsbeschreibungen üblicherweise hingewiesen? Kann eine Anwendung, die von stored routines Gebrauch macht, dadurch größere Schwierigkeiten bekommen, falls man auf einen anderen Server bei einem anderem Hoster umziehen will?
Ranma