CronJob-Service
bei SELFPHP mit ...
|
+ minütlichen Aufrufen
+ eigenem Crontab Eintrag
+ unbegrenzten CronJobs
+ Statistiken
+ Beispielaufrufen
+ Control-Bereich
Führen Sie mit den CronJobs von
SELFPHP zeitgesteuert Programme
auf Ihrem Server
aus. Weitere Infos
|
:: Anbieterverzeichnis ::
Globale Branchen
Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP
:: Newsletter ::
Abonnieren Sie hier den kostenlosen
SELFPHP Newsletter!
|
PHP Grundlagen Hier kann über grundlegende Probleme oder Anfängerschwierigkeiten diskutiert werden |
31.08.2009, 15:59:22
|
Anfänger
|
|
Registriert seit: Jan 2009
Alter: 36
Beiträge: 12
|
|
MySQL: Rekursiv
Hallo, ich habe ein ziemliches Problem. Undzwar schreibe ich gerade ein eigenes Forum. Ich kann aus verschiedenen Gründen kein fertiges nehmen, aber darum geht es hier nicht.
Ein Forum kann beliebig viele ineinander verschachtelte Unterforen haben.
Die Frage ist nun folgendes: Wie finde ich heraus, ob das Unterforum betreten werden darf, wenn ich nur die Unterforum ID habe? Ein Forum oder ein Unterforum bekommt ein rank_visible-wert. Ist dieser =4 bedeutet es, dass es nur Admins sehen dürfen.
Forum 1
Forum 2 ist in Forum 1 eingegliedert
Forum 1 hat rank_visible=4, forum 2 nicht.
Wie finde ich nun heraus, dass Forum 2 von einem User nicht betreten werden darf, weil ja Forum 1 nur für Admins ist?
Muss ich da alle rank_visibles rückwärts durch gehen, bis diese sich ändert?
lg
|
31.08.2009, 16:33:30
|
SELFPHP Experte
|
|
Registriert seit: Jun 2008
Alter: 15
Beiträge: 2.269
|
|
AW: MySQL: Rekursiv
Ja.
Man kann zwar rekursiv löschen (15 Ebenen tief), aber nicht SELECTen.
Du könntest alternativ auf "Nested Sets" umsteigen.
|
31.08.2009, 17:28:21
|
Anfänger
|
|
Registriert seit: Jan 2009
Alter: 36
Beiträge: 12
|
|
AW: MySQL: Rekursiv
Zitat:
Zitat von DokuLeseHemmung
Ja.
Man kann zwar rekursiv löschen (15 Ebenen tief), aber nicht SELECTen.
Du könntest alternativ auf "Nested Sets" umsteigen.
|
Ich hab das jetzt so gelöst, dass ich eben damit lebe. :) Der Admin hat dann eben auch darauf zu achten, dass er die Rechteverteilung auch in den Unterforen richtig einstellt. Ich denke das ist kein Problem. Man könnte es auch als ein Feature betrachten, zumal man dann bestimmte Forenbereiche wieder öffnen kann.
Dabei bleibt nur die Frage wie ich das mache, dass dann das Forum mit Rank_visible=4 trotzdem gelistet wird, weil es irgendwo ein Unterforum hat, wo auch User mit einem schwächeren Rank willkommen sind... Ich denke darauf muss ich dann verzeichten. Man kann ja für den Fall auch den Link des Unterforums weiter geben. Außerdem wird dies in der Praxis eh extrem selten verwendet.
Was sind "Nested Sets"? Davon hab ich noch nicht gehört.
Edit:
Code:
CREATE TABLE `forum` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`order` bigint(20) NOT NULL,
`parent_id` bigint(20) NOT NULL,
`user_id` bigint(20) NOT NULL,
`user_name` varchar(128) NOT NULL,
`date_created` datetime NOT NULL,
`date_edited` datetime NOT NULL,
`ehit_count` bigint(20) NOT NULL,
`is_closed` tinyint(1) NOT NULL,
`rank_visible` tinyint(3) NOT NULL,
`type` tinyint(1) NOT NULL COMMENT '0=Forum;1=Thread;2=Post;3=Spacer',
`post_count` bigint(20) NOT NULL,
`themes_count` bigint(20) NOT NULL,
`latest_post_id` bigint(20) NOT NULL,
`is_sticky` tinyint(1) NOT NULL,
`is_top` tinyint(1) NOT NULL,
`is_announce` tinyint(1) NOT NULL,
`mods` varchar(255) NOT NULL,
`title` varchar(255) NOT NULL,
`content` text NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;
So sieht die Tabelle für das (gesamte!!) Forum aus.
Wie parent_id schon sagt, lässt sich damit alles Mögliche in einander verschachteln.
ehit_count ist kein Tippfehler. Dieses Feld wird gleichzeitig für die Anzahl der Edits bei einem Thread oder Post, als auch für die Anzahl der Hits bei einem Forum oder verwendet :).
Interesant wird es auch, wenn ein Post in einem Thread gemacht wird. Dann muss ich rückwärts die Struktur durchgehen und dort die Anzahl der Posts sowie die ID des neusten Posts zu aktualisieren. Ist aber kein Problem.
Ähnliches habe ich auch realisiert um den Pfad in dem der User sich gerade befindet anzuzeigen. :)
lg
Geändert von BloodySword (31.08.2009 um 17:39:43 Uhr)
|
31.08.2009, 18:18:01
|
SELFPHP Experte
|
|
Registriert seit: Jun 2008
Alter: 15
Beiträge: 2.269
|
|
AW: MySQL: Rekursiv
Du könntest Google oder irgendeine andere SUMA befragen...
|
31.08.2009, 18:22:56
|
|
Senior Member
|
|
Registriert seit: Nov 2003
Ort: Kempten @ Allgäu
Alter: 36
Beiträge: 1.408
|
|
AW: MySQL: Rekursiv
nested sets ... guter Input! Aber werden die in der Praxis wirklich viel verwendet? Bisher hab ich mir das eigentlich immer "von Hand" zusammengebaut, ist halt die Frage, wie viel von der performance rüberkommt und ob das den Aufwand gerechtfertigt.
__________________
the best way to be ready for the future is to invent it
|
31.08.2009, 18:57:10
|
SELFPHP Experte
|
|
Registriert seit: Jun 2008
Alter: 15
Beiträge: 2.269
|
|
AW: MySQL: Rekursiv
Ist natürlich nervig, wenn man das selbst klöppelt. Aber es gibt ja einiges vorgefertigtes.
Z.B.: http://www.doctrine-project.org/docu...rarchical-data
Ist genial, damit ist es ein Kinderspiel.
Und die Leseperformance steigt mit der tiefe des Baumes, im Verhältnis zu binär Bäumen.
Und schwächelt beim ein/austragen von Blättern/Knoten.
|
01.09.2009, 10:12:03
|
|
SELFPHP Guru
|
|
Registriert seit: May 2003
Beiträge: 7.187
|
|
AW: MySQL: Rekursiv
Zitat:
Zitat von DokuLeseHemmung
Und die Leseperformance steigt mit der tiefe des Baumes, im Verhältnis zu binär Bäumen.
Und schwächelt beim ein/austragen von Blättern/Knoten.
|
Absolut, wobei die Schreibperformance in einem Forum sicherlich vernachlässigbar ist, so lange nur die Forenstruktur und nicht die Beiträge damit abgebildet werden. Auf der anderen Seite muss man sich aber auch fragen, ob die Forenstruktur wirklich so ausgeprägt sein wird, dass Lesezugriffe auf eine Nested Set-Datenstruktur merkbar schneller sind.
Gruß
|
01.09.2009, 10:59:34
|
Anfänger
|
|
Registriert seit: Jan 2009
Alter: 36
Beiträge: 12
|
|
AW: MySQL: Rekursiv
Ich jedenfalls hab mich entschieden so weiter zu machen wie bisher. Ich denke das ist vollkommen ausreichend, nicht wahr? (Siehe Tabelle)
Es werden vielleicht noch die ein oder anderen Spalten entfernt oder hinzugefügt werden aber sonst sehe ich das ganze schon als stabil genug an.
BTW.: Weiß jemand von euch wie man eine Baumansicht mit Smarty rendert? Mit {foreach} wird das nicht gehen, ich müsste dann ja im template unendlich viele {foreach} schachteln.
lg
|
01.09.2009, 11:11:41
|
|
Senior Member
|
|
Registriert seit: Nov 2003
Ort: Kempten @ Allgäu
Alter: 36
Beiträge: 1.408
|
|
AW: MySQL: Rekursiv
Zitat:
Zitat von BloodySword
BTW.: Weiß jemand von euch wie man eine Baumansicht mit Smarty rendert? Mit {foreach} wird das nicht gehen, ich müsste dann ja im template unendlich viele {foreach} schachteln.
lg
|
Rekursion ist das Zauberwort. Du kannst nämlich auch in Smarty so kleine Funktionen bauen, außerdem kannst du teilweise PHP-Funktion verwenden, denke da daran zu übrtprüfen mit empty(), isset() usw, geht alles einfach so in Smarty.
__________________
the best way to be ready for the future is to invent it
|
01.09.2009, 12:52:18
|
Anfänger
|
|
Registriert seit: Jan 2009
Alter: 36
Beiträge: 12
|
|
AW: MySQL: Rekursiv
Ich schau mal in die Smarty-Doku oder mit Google. Wenn ich dort nichts finde komme ich nochmal auf euch zurück ^^'.
Vielen Dank!
Geändert von BloodySword (01.09.2009 um 13:04:10 Uhr)
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
Forumregeln
|
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +2. Es ist jetzt 15:42:39 Uhr.
|