Allgemeines 21.967 Themen, 148.269 Beiträge

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

schnaffke / 17 Antworten / Flachansicht 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
Kopfschütteln Tilo Nachdenklich
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