Zur Navigation

Bewertungen von Beiträgen

Umsetzung in SQL?

1 Ranma (Gast)

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

17.04.2015 13:12

2 Jörg

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?

Die Query selbst kannst du doch im PHP-Script "speichern"?

Du kannst aber auch Stored Procedures anlegen:

http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-stored-procedures.html

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).

Genau das ist in diesem Forum der Fall, man kann nur einmal auf den Danke-Button klicken (wenn man als registrierter User eingeloggt ist)

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?

Da kannst du entsprechende Grenzwerte definieren, z.B.:

1 Antwort: 1 Stern
2 - 3 Antworten: 2 Sterne
4 - 7 Antworten: 3 Sterne
8 - 15 Antworten: 4 Sterne
> 15 Antworten: 5 Sterne

17.04.2015 15:54 | geändert: 17.04.2015 15:54

3 Ranma (Gast)

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

18.04.2015 05:34

4 Ranma (Gast)

Der Danke-Button bringt mich auf eine Idee. Falls sich nämlich der Aufwand lohnt, für jeden Nutzer festzustellen, ob der auf einen bestimmten Knopf gedrückt hat, dann sollte sich auch der Aufwand lohnen festzustellen, welcher Beitrag von welchem Nutzer gelesen wurde. Das sollte der gleiche Aufwand sein und relativ aussagekräftig. Wie oft ein Beitrag insgesamt gelesen (oder aufgerufen) wird, ist vielleicht mit etwas weniger Aufwand gleichermaßen aussagekräftig in Bezug auf die Qualität des gelesenen Beitrages.

Zu bedenken ist allerdings noch, daß man wohl nicht feststellen kann, ob ein Beitrag tatsächlich gelesen wird, sondern nur ob er aufgerufen wird. Da gibt es dann noch Leute, die alles Klickbare anklicken. Aber zumindest erwarte ich keine Verfälschung durch solche Leute, sondern eher eine Art schwaches Grundrauschen. Dann gibt es noch Leute, die einen Titel mißverstehen. Ein Titel kann mißverständlich formuliert sein und Leute abschrecken (aber die lesen den Beitrag nicht und da nützt es nichts, wenn der noch so gut ist) oder Leute versehentlich anlocken. In dem Fall müßte man feststellen, ob der betreffende Beitrag sofort wieder verlassen wird. Das wäre dann als Versehen zu werten und von der Gesamtwertung wieder abzuziehen.

Sollten es einzelne Beiträge natürlich schaffen in einer Suchmaschine gelistet oder anderswo verlinkt zu werden, dann könnten sie externe Besucher anlocken und das würde auf eine hohe Qualität hinweisen. Das sollte ein gerechtes Bewertungssystem auf jeden Fall berücksichtigen, sofern es möglich ist. Das sollte möglich sein, sofern man die Referer-Abfrage noch beim Aufrufen der einzelnen Texte ins Skript gequetscht kriegt. (Mein Testskript ruft zur Zeit nur auf, wenn ich die Absicherung einer dafür erforderlichen GET-Variable entferne.)
Ranma

19.04.2015 04:55

5 Jörg

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.

19.04.2015 19:46

6 Ranma (Gast)

Zum ausprobieren bin ich erstmal damit zufrieden, die Berechnung eines arithmetischen Mittels von MySQL ausführen zu lassen. Danach kann ich mich immernoch an Komplizierteres wagen.

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?

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

20.04.2015 05:04

7 Jörg

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.

20.04.2015 21:15

8 Ranma (Gast)

Anfangs bin ich vor SQL zurückgeschreckt und suchte sogar immer erst nach Alternativen zur Verwendung einer Datenbank. In letzter Zeit, als ich es endlich ausprobierte, fand ich SQL überraschend einfach. Jetzt kommt es mir so vor als könnte SQL wirklich das Grauen sein, das ich anfangs fürchtete. Vielleicht sogar noch schlimmer.

Wieso sollte ich Tabellen mit JOIN verknüpfen, wenn ich auch gleich alles (also alles, was ich sonst verknüpfen müßte, davon Unabhängiges natürlich nicht) in eine Tabelle schreiben kann?

Normalisierung habe ich noch nie verstanden. Das ist also das Gegenteil von Redundanz?
Solange ich immer in die selbe Tabelle schreibe, wird ja nichts redundant. Wahrscheinlich muß man Informatiker sein, um die Normalisierung, dazu noch mit ihren ganzen Unterformen, zu verstehen.
Ranma

21.04.2015 07:07

9 Ranma (Gast)

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

22.04.2015 08:19

10 Jörg

Solange ich immer in die selbe Tabelle schreibe, wird ja nichts redundant.

In dem Wikipedia-Artikel sind ja Beispiele aufgeführt. Bei einer fehlenden Normalisierung muss sich die (PHP-)Applikation um die Konsistenz kümmern. Das kann man z.B. aus Performance-Gründen in Einzelfällen durchaus so machen. Aber das erhöht natürlich die Komplexität und Fehleranfälligkeit der Applikation.

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:

[...]

Es könnte also sein, daß sich der Aufwand garnicht lohnt.

Du kannst auch ohne Stored Procedures in MySQL rechnen. Ich hatte diese nur erwähnt, weil du danach gefragt hattest, ob man "Formeln" auch in der Datenbank speichern kann.

Wenn man diese nutzen kann, ist es aber von Vorteil, dass man Strings, Integer etc. nicht mehr einzeln maskieren muss, um die Queries gegen SQL-Injection abzusichern.

22.04.2015 16:48