Allgemeines 22.060 Themen, 149.947 Beiträge

Verfolgung starten Optionen

Gelöschte Postings, Antworten nicht nachvollziebar....

schnaffke / 17 Antworten / Baumansicht Nickles

Hallo alle zusammen, also was TW privat macht interessiert mich nicht, ich hab hier nur mal ne allgemeine Anregung. Also wenn ein Posting gelöscht wird (weswegen auch immer), es dazu aber Antworten gibt, dann versteht natürlich keiner mehr die Antwort (ist mir kürzlich passiert, ich hatte auf ein Posting geantwortet, am nächten Tag war das Posting weg, meine Antwort aber noch da). Lediglich ein schmaler grauer horizontaler Streifen oberhalb meiner Antwort deutet noch darauf hin, dass da mal ein Posting war. Wäre es nicht möglich, hier ein kurzes Statement abzugeben, z.B. Posting wurde gelöscht.


 Meine Antwort wurde so innerhalb der ganzen Diskussion dadurch jedenfalls ziemlich unverständlich und nicht nachvollziehbar.
Gruß Schnaffke



 

bei Antwort benachrichtigen
Pitje_Puck schnaffke „Gelöschte Postings, Antworten nicht nachvollziebar....“
Optionen

Im Normalfall ist das ja so, dass wenn die entsprechende ThreadID gelöscht wird, werden die "TochterID"s dazu auch gelöscht, sind bei Threads nicht mehr einsehbar, von daher wirds wieder logisch, gut wenn man in der Flachansicht anwortet, stimmt es, was du sagst, aber so interessant waren die posings auf OT nun auch nicht, dass ich jetzt hinterhergiere, was da wohl wer auf was geantwortet hatte. Meistens wird eh nur mist gelöscht denke ich mal und wenn man auf Mist anworten lesen will, so ist das meist eh nur mist.

bei Antwort benachrichtigen
xafford schnaffke „Gelöschte Postings, Antworten nicht nachvollziebar....“
Optionen

Exakt aus diesem Grund (und aus noch einigen anderen) ist es sinnvoller immer direkt auf ein Posting zu antworten, so daß es in den entsprechenden Zweig eingehängt wird. Also zum Antworten immer den Link untendrunter nutzen mit "Auf dieses Posting antworten".
Beim Löschen verschwindet nämlich der ganze Ast.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Pitje_Puck xafford „Exakt aus diesem Grund und aus noch einigen anderen ist es sinnvoller immer...“
Optionen

Die Flachansicht ist eigentlich auch nur dazu praktisch, damit man alle Postings auf einen Blick sehen kann und nicht den ganzen Baum durchklicken muss.

By the Way:
Meines Wissens nach nennt man diese Funktionen, auf diesen die Baumstruktur auch beruht, rekursive Funktion. Liege ich da noch richtig oder gibt es mittlerweile bessere Möglichkeiten, Foren auf Baumstrucktur oder Threadstruktur aufzubauen

bei Antwort benachrichtigen
xafford Pitje_Puck „Die Flachansicht ist eigentlich auch nur dazu praktisch, damit man alle Postings...“
Optionen

Da bin ich ehrlich gesagt überfragt, ich habe noch nie mit der Programmierung von Foren zu tun, aber so aus dem Stehgreif denke ich, daß rekursion die einzige Möglichkeit ist Baumstrukturen beliebiger Tiefe zu erstellen mit einem sinnvollen Aufwand und Speicherbedraf.
BTW, mich wundert, daß diesen Algorithmus noch niemand patentiert hat.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
Pitje_Puck xafford „Da bin ich ehrlich gesagt überfragt, ich habe noch nie mit der Programmierung...“
Optionen

Was würde eine Patentierung für den Heimprogrammierer bedeuten?

bei Antwort benachrichtigen
Tilo Nachdenklich Pitje_Puck „Was würde eine Patentierung für den Heimprogrammierer bedeuten?“
Optionen

Kopfschütteln

bei Antwort benachrichtigen
Pitje_Puck Tilo Nachdenklich „Kopfschütteln“
Optionen

Das kann ich mir nicht vorstellen, dass das die Konsequenz für den Heimprogrammierer ist

bei Antwort benachrichtigen
Borlander xafford „Da bin ich ehrlich gesagt überfragt, ich habe noch nie mit der Programmierung...“
Optionen

Hallo xaf,
meines Wissens nach gibt es noch mindestens eine weitere Methode zur Darstellung. Diese ist beim Auslesen schneller (da die Unterobjecte bereits in geordneter Reihenfolge vorliegen und nur noch entsprechend eingrückt werden müssen) - eignet sich aber nicht wenn häufig neue Elemente eingefügt werden sollen. Ist vom Aufwand mit rekursiven Bäumen vergleichbar (mit den richtigen SQL-Anweisungen), Speicherbedarf dürfte sogar geringer sein da das Ausgabescript das Ergebnis nicht zur Sortierung zwischenspeichern muss (mal abgesehen vom wenig performanten rekursiven Auslesen der DB).

Bei Interesse könnte ich einen Artikel dazu raussuchen...


CU Borlander

bei Antwort benachrichtigen
Pitje_Puck Borlander „Hallo xaf, meines Wissens nach gibt es noch mindestens eine weitere Methode zur...“
Optionen

Es besteht Interesse, ja sogar reges Interesse :-)

Danke sehr

bei Antwort benachrichtigen
xafford Borlander „Hallo xaf, meines Wissens nach gibt es noch mindestens eine weitere Methode zur...“
Optionen

Ja, interessiert mich auch...das hat nicht zufällig was mit *-baum zu tun?

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
pco xafford „Ja, interessiert mich auch...das hat nicht zufällig was mit -baum zu tun?“
Optionen

Bei der Entwicklung einer ganz ähnlichen Idee vor ein paar Monaten hab ich mich gefragt, warum Robin Hood nur so viel Hash geraucht hat...

Nebenbei...

Ich seh die Lösung in B-Trees (nicht zu verwechseln mit Binärbäumen). Hierdurch würde das "umhängen" der Nodes zum Kinderspiel und man könnte einzelne Entitys aus einem Node entfernen, ohne dass die Ordnung verloren geht... Ein Node würde existieren, solange mindestens ein Entity existiert.

Das ist aber rein philosophisch, da sowas bei der generierung der Datenstruktur beachtet werden muss.

PCO

bei Antwort benachrichtigen
xafford pco „Bei der Entwicklung einer ganz ähnlichen Idee vor ein paar Monaten hab ich mich...“
Optionen

Von der Theorie her ganz einleuchtend, mir stellt sich aber die Frage, wie man einen B-Baum in einer MySQl Datenbank abbilden soll, also die reale Umsetzung.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
pco xafford „Von der Theorie her ganz einleuchtend, mir stellt sich aber die Frage, wie man...“
Optionen

Durch geschickte Vergabe von 2 Schlüsseln (IDs), würde ich spontan schätzen.
Ansatz 1970 von R. Beyer (ja ich habe nachgeschlagen, son Sch.. hat man nicht im Kopf):

Im Prinzip sind B-Bäume N-ärbäume mit einfach verketteten Listen als Nodes.
Jedes 1-Tupel kann also einen Node und ein weiteres 1-Tupel als Followup haben.

Abstrahiert könnte man also annehmen, ein Node ist das Ergebnis genau einer SQL-Anweisung mit der Bedingung threadid.

Ein Thread ist "endlich", also haben wir auch diese Bedingung an Nodes erfüllt.

Gehen wir bspw. davon aus, dass ein Thread maximal 30 Antworten hat, dann haben wir log(30)n Aufwand etwas zu suchen. Mittelmässig.

Pseydo-Code:
item->ID; //Repräsentant des Elementes/Postings
item->(integer)threadid; //DS gehört zu thread-id (So bauen wir Select auf)
item->(integer)nextentity_ID; //Nachfolge-Node, so vorhanden
item->(string)content; //Inhalt des DS

$page = Recordset of items //Sprich: Ergebnis einer SQL-Anweisung über threadid

Was ist der Vorteil?
Die Recordsets in jeder Operation werden kleiner.
Geschickt zerlegt können Subthreads gelöscht werden, indem man sie einfach "aushängt". Splitting etc. alles kein Problem...

Wählt man für die Generierung der Schlüssel Daten und Uhrzeiten, so kann man es geschickt anstellen und eine Datumsbasierende suche mit relativ geringem Aufwand generieren.

Problem:
Damit der Aufwand sinn macht, muss ich zuerst einen Select mit Nodes haben, in welchem ich dann wiederum einen Node auswähle. Dies macht Subselects notwendig - nicht in jeder Mysql-Version schon "drin".

Nach der Methode lassen sich übrigens prima Usermanager mit Gruppenrichtlinien basteln...

Und das ist noch nicht mal zuende gedacht...

Bye

PCO

bei Antwort benachrichtigen
xafford pco „Durch geschickte Vergabe von 2 Schlüsseln IDs , würde ich spontan schätzen....“
Optionen

Ok, du hast also zwei IDs für eine verkettete Liste. Aber wie soll sich denn eine Baumstruktur beliebiger Tiefe als verkettete Liste realisieren lassen? Einmal ein konkretes Beispiel eines Thread:






Tread_1


   Reply_1_Thread_1


   Reply_2_Thread_1


      Reply1_Reply_2_Thread_1


         Reply_1_Reply_1_Reply_2_Thread_1


      Reply2_Reply_2_Thread_1


   Reply_3_Thread_1

Problem ist ja, daß ein Element des Baumes mehr als einen nächsten Node haben kann, wie man oben sieht. Somit kann ich mit NextEntity nicht operieren, da ja meines Wissens das Kriterium für eine verkettete Liste ist, daß ich genau einen Vorgänger und einen Nachfolger hat, oder?
Gehen könnte es über PreviousEntity, da ja ein Followup nur Followup von einem Vorgänger sein kann.
Und mit einem Subselect bin ich ja schon wieder bei einer Rekursion, denn ob die Rekursion nun das Script, oder die Datenbank macht ist egal.
Ergo könnte man nur über die ID des Vorgängers operieren schematisch ungefähr so im SELECT:
SELECT PARENT,INHALT FROM THREADS WHERE THREAD=GEWUENSCHTER_THREAD

PARENT ist dann die id des Post, auf welches das betreffende Post ein Kind ist und wird dann im Script zum Einhängen genutzt. So könnte man eventuell ohne Rekursion einen Thread aufbauen oder habe ich einen Denkfehler?
Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
pco xafford „Ok, du hast also zwei IDs für eine verkettete Liste. Aber wie soll sich denn...“
Optionen

>ob die Rekursion nun das Script, oder die Datenbank macht ist egal.
Ich würde die Datenbank bevorzugen, da das laufzeitverhalten da besser st.

Was die Datenstruktur des B-Baumes angeht, denke ich du bist noch zu sehr bei Binärbäumen. Beim B-Baum kann jedes Tupel eines Nodes ein neues Tupel, als auch einen ganzen Node als Nachfolger haben.

Der Baum selber wird Rekursiv aufgebaut, das lässt sich kaum anders machen. Die Nodes jedoch werden Iterativ durchsucht.

Sprich mit deinem Beispiel
Du suchst mit Deienr Select-Anweisung alle Replys zu Thread 1.
Ergebnis ist

function rekursion(thread)
{
Replies = sql(SELECT * FROM threads WHERE thread.parentid='thread.id'); //ergebnis im Beispiel reply_1, reply_2

//Jetzt wirds iterativ
For each(Reply in Replies)
if (Reply.nextnode) //wir haben einen node als follow_up
set new newnode as reply; //Okay neuer Node
newnode.id = reply.nextnode; //Node.id muss nextnode des Vorgängers sein.
rekursion(reply)
else
show_reply(reply); //rekursionsabbruch
}

Dank dieser Funktion kann ich an jedem Punkt in den Thread springen...

Ich habe die Datenstruktur um einen "Nextnode" erweiter, dafür allerdings das Nextentity weglassen können.

Wichtig ist der Iterative abschnitt, welcher Speicher sparen kann, da Follow-Ups nicht als Teil der Rekursion, sondern als Sequenz gesehen werden. Der B-Baum ist in der lage zu Listen degenerierte Bäume mit dem Aufwand von exakt "n" abzuarbeiten.
Bedeutet: Ein Thread hat nur Follow_Ups ohne eigene Follow_Ups. In diesem Falle wird die Rekursion hier nur ein mal im Skript durchlaufen.

In Deinem Beispiel wächst die Komplexität sehr schnell, da Du mehrere Verschachtelte Abbruchbedingungen einbauen musst und in dem Falle Du wahrscheinlich durch die iterative Methode keinen Speicher sparst.

PCO

bei Antwort benachrichtigen
xafford pco „ ob die Rekursion nun das Script, oder die Datenbank macht ist egal. Ich würde...“
Optionen

Hi PCO,

bei dem Ansatz mit einer Rückwärtsverketteten Liste hätte ich doch gar keine Interationen nötig. Einmal angenommen die Datenbank wäre (vereinfacht) so aufgebaut:

ID | ThreadID | ParentID | Inhalt

dann würde ein einziger Select reichen um einen kompletten Thread (oder auch mehrere) auszulesen und ihre Struktur eindeutig zu bestimmen:

SELECT ID,ThreadID,ParentID,Inahlt FROM Forum WHERE ThreadID=1;
somit hätte ich den kompletten Thread 1 und die Zeile ohne Parent ist das Anfasngsposting.
Wenn ich das Abfrageergebnis jetzt aufbauen will muß immer nur jeweils ein Kindpost hier das Post gestellt werden, dessen ParentID es gesetzt hat.
Mit einem ausgefeilteren SELECT-Statement liese sich der Thread sogar gleich von der Datenbank in die richtige Reihenfolge bringen, z.B. mit einem GROUP BY ParentID und ORDER BY.
Eine Rekursion in der Datenbank wäre nur dann mit Sicherheit schneller, wenn sie mit einer Anfrage generiert würde. Muß ich innerhalb eines Scripts mehrmals Anfragen aufbauen, so könnte das unter Oracle z.B. ein riesiges Problem werden, da da ein Verbindungsaufbau sehr teuer ist.

Pauschalurteile sind immer falsch!!!
bei Antwort benachrichtigen
schnaffke Nachtrag zu: „Gelöschte Postings, Antworten nicht nachvollziebar....“
Optionen

Hallo Jungs, ich antworte jetzt absichtlich nicht als "Tochter" oder "Unter" Antwort, weil ich das damals auch nicht beabsichtigt hatte. Stellt euch vor, es wäre eine allgemeine Antwort auf ein Posting von einem User ( z.B. Xafford, weiter oben in diesem Thread, nur als Beispiel ).Nehmt diesen Thread also nur als Beispiel, für das, was ich meine. Stellt euch weiter vor, Xafford hätte in seinem Posting etwas negatives über andere User verbreitet (wie gesagt, nur ein Beispiel, bezogen auf diesen Thread). Jetzt wird das erste Posting von Xafford gelöscht und alle "Tochter"-Postings.
Dann ergibt dieses Posting doch überhaupt keinen Sinn mehr.
Sorry Xafford, dass ich dich jetzt als Beispiel nehme, hat auch überhaupt nichts mit dem Inhalt zu tun, sondern nur mit der Strucktur der Postings, das passte gerade so gut zu dem, was ich meinte.
Also stellt euch vor, ihr lest meine Eingangsfrage, (inzwischen ist Xaffords Posting mit allen Anhängen gelöscht worden) dann die Antwort von Pitje_Puck und dann diese hier (weil ja Xafford und Anhang gelöscht wurde, als Beispiel).
DIESE Antwort wäre doch komplett unverständlich, deshalb wollte ich vorschlagen, gelöschte Postings als solche zu markieren, so etwa " Dieses Posting wurde gelöscht" oder so ähnlich.
Wäre doch eine Hilfe für verunsicherte User.
Gruß Schnaffke

bei Antwort benachrichtigen