Jetzt gibt es eine Beitragstabelle (die Struktur kann nicht geändert werden)
TID-Thema-PID
PID-Antwort-ID
Jetzt wird eine neue Funktion zur Anzeige von Kommentarverschachtelungen hinzugefügt, d. h. tid=1
a hat einen Kommentar mit einer PID von 1 kommentiert
b hat auf den Kommentar von a mit einer PID von 2 geantwortet
c hat darauf geantwortet b's Kommentar mit einer PID von 2 3
d antwortete mit einer PID von 4
wird angezeigt als
pid1 im 1. Stock
pid1, pid2 im 2. Stock
pid1, pid2, pid3 im 3. Stock
pid1, pid4 im 4. Stock
Das Das heißt, jede Antwort an andere muss zitiert werden. Alle vorherigen Antworten.
(Das Format ist das gleiche wie bei den Kommentaren zu NetEase News)
Ich denke derzeit an eine Struktur, die post_conversation pid, to_pid ist
Auf diese Weise wird die Antwort im 2. Stock 2,1 einfügen
<code> 3楼回复就插入两条 3,1 3,2 4楼回复就插入 4,1 </code>
Wenn im 99. Stock ein Gespräch stattfindet, müssen 98 Daten eingegeben werden
<code>这样有个好处就是可以很方便取出任意一个pid的评论情况 select topid from post_conversation where pid = 'xxx' order by pid ; 但是会造成多的重复数据 一个99楼对话得插入1+2+3+。。。+99条 </code>
Wenn post_conversation so gestaltet ist
pid, parent_pid (die PID, auf die geantwortet wird)
Die Datenmenge ist gering (für jede Antwort wird nur eine Nachricht eingefügt);
Aber es werden alle Konversationen abgefragt Jede PID ist ein sehr schwieriges Problem (ich denke darüber nach, die Datenbank rekursiv abzufragen).
<code>select parent_pid from post_conversation where pid = 'xxx' select parent_pid from post_conversation where pid = 'parent_pid ' ... 一直到parent_pid 为0为止,查询出所有的对话pid </code>
Antwortinhalt:
TID-Thema-PID
PID-Antwort-ID
a hat einen Kommentar mit einer PID von 1 kommentiert
b hat auf den Kommentar von a mit einer PID von 2 geantwortet
c hat darauf geantwortet b's Kommentar mit einer PID von 3
d antwortete mit einer PID von 4
pid1 im 1. Stock
pid1, pid2 im 2. Stock
pid1, pid2, pid3 im 3. Stock
pid1, pid4 im 4. Stock
Das Das heißt, jede Antwort an andere muss zitiert werden. Alle vorherigen Antworten.
(Das Format ist das gleiche wie bei den Kommentaren zu NetEase News)
Ich denke derzeit an eine Struktur, die post_conversation pid, to_pid ist
Auf diese Weise wird die Antwort im 2. Stock 2,1 einfügen
<code> 3楼回复就插入两条 3,1 3,2 4楼回复就插入 4,1 </code>
<code>这样有个好处就是可以很方便取出任意一个pid的评论情况 select topid from post_conversation where pid = 'xxx' order by pid ; 但是会造成多的重复数据 一个99楼对话得插入1+2+3+。。。+99条 </code>
pid, parent_pid (die PID, auf die geantwortet wird)
Die Datenmenge ist gering (für jede Antwort wird nur eine Nachricht eingefügt);
Aber es werden alle Konversationen abgefragt Jede PID ist ein sehr schwieriges Problem (ich denke darüber nach, die Datenbank rekursiv abzufragen).
<code>select parent_pid from post_conversation where pid = 'xxx' select parent_pid from post_conversation where pid = 'parent_pid ' ... 一直到parent_pid 为0为止,查询出所有的对话pid </code>
Danke für die Einladung
Früher habe ich die primitivste rekursive Abfragemethode verwendet, um eine unendliche Verschachtelung (Menüs, Kommentare) zu erreichen. Später habe ich einen Artikel gesehen, der vom Administrator in der Laravel-China-Community gepostet wurde. Die Artikeladresse lautet https://laravel-china.org/topics/2124. Er verwendet
, um ein unendliches baumartiges hierarchisches Modell zu implementieren (Tag System, Menüsystem, Kommentarsystem usw.). Das Thema kann sich auf Folgendes beziehen.
预排序遍历树算法(Nested set model)
Ein Artikel entspricht mehreren Kommentaren und ein Kommentar entspricht mehreren Antworten.
Q&A-Community segmentfault.com und Tencent News verwenden beide „Antworten auf Kommentare“.
Nehmen Sie segmentfault als Beispiel:
Der Fragesteller (der Originalposter) hat eine Frage gepostet, und diese Frage hat mehrere Antworten (der Bodenbesitzer). ). Die Datenbank ist eine Eins-zu-Viele-Beziehung.
Jede Antwort kann mehrere Antworten haben, was ebenfalls eine Eins-zu-Viele-Beziehung ist.