Content Management Framework Addon

[ragtek]

Zumal Du mit den zusätzlichen Joins die Datenbank dann noch mehr belastest. Ich glaube nicht, dass der Entwickler verstanden hat, was mit der Nutzung der Infrastruktur gemeint war.

Ich kenne jetzt xFs Core nicht, ich habe mich dort nicht eingearbeitet. Aber es sollte doch möglich sein die Klassen des Cores (also Report, Moderation etc) auch in eigenen Applikationen mit eigenen Contenttypen zu verwenden, oder nicht?

jop und es ist SOBALD man es verstanden hat (und die caches aktualisiert hat, die mich pers. die meißten Nerven gekostet haben), auch extrem einfach....
Nur ja, oft siegt die Faulheit / das nicht Wissen....

Man braucht sich mittlerwile ja nur das Blog Add-on anschauen, benutzt keine Threads und bietet fast alles...(das leider zu spät gekommen ist, sonst gäbe es eventuell das artikel addon auch schon )

 

[ragtek]

Als Bsp, Artikelsystem benutzt alles mögliche (alert, attachment, modqueue,node,like,newsfeed,report)

 

[Hatsu]

OOP ist halt doch nicht für jedermann

 

[Haddawas]

Das Rechtemanagement stelle ich mir auch sehr spannend vor

ist es denn einfacher 1000 foren mit threads posts und dateianhängen zu verwalten
Profile mit freundschaften und Privatsphäreneinstellungen

Die Moderation hat entschieden, dass alle beiden Blogeinträge von Hugo zum Themenblog von Rita hinzugefügt werden sollen. Dazu wird die komplette Posttabelle mit 1,2 Millionen Beiträgen durchsucht.

wieso durchsucht? bei einem Forum mit 1Mio Beiträge muss auch mehr durchsucht bzw. verwaltet werden auch auch wenn ich in einem Unterforum suche das nur 2 threads beinhaltet

Ein Galeriebild hat schon wieder ganz andere Merkmale, die die anderen nicht haben. Auf die Schnelle fallen mir da ein Abmessungen, Dateigröße, Dateiformat und bestimmt noch viele Dinge mehr. Wenn Du kontrollieren willst, was Deine Nutzer hochladen musst Du so etwas auch erfassen.

ein Galeriebild ist ein Thread wo im ersten Beitrag nur ein Dateianhang ist, in weiteren Kommentaren brauchst du dazu nicht mal die Dateianhangsfunktion, diedarstellung wird also reduziert

---
ja es gibt sicher Punkte die ein Problem sein können, aber wo sind die Unterschiede zu jetzigen Featureumfängen
der Unterschied ist das es aus unterschiedlichen Tabellen jetzt alles aus nur einem Contentpool gefischt wird

 

[Hatsu]

ist es denn einfacher 1000 foren mit threads posts und dateianhängen zu verwalten
Profile mit freundschaften und Privatsphäreneinstellunge

Ich rede nicht vom Rechtemanagement, welches Du im ACP einstellst, sondern ich rede vom Rechtemanagement, dass Du programmieren musst, dass Du überhaupt was im ACP einstellen kannst und welches dann im Frontend auch richtig funktioniert.

wieso durchsucht? bei einem Forum mit 1Mio Beiträge muss auch mehr durchsucht bzw. verwaltet werden auch auch wenn ich in einem Unterforum suche das nur 2 threads beinhaltet

Wie außer durch Suchen sollen die beiden von mir genannten Beiträge denn gefunden werden?

ein Galeriebild ist ein Thread wo im ersten Beitrag nur ein Dateianhang ist, in weiteren Kommentaren brauchst du dazu nicht mal die Dateianhangsfunktion, diedarstellung wird also reduziert

Ein Galeriebild ist eben KEIN Thread. Ich kann es mir solange zurecht basteln bis einer draus wird, aber sowas nennt man Gefrickel. Was in einem Frontend zu sehen ist, hat mit dem Backend der Datenbank mal überhaupt nichts zu tun.

ja es gibt sicher Punkte die ein Problem sein können, aber wo sind die Unterschiede zu jetzigen Featureumfängen
der Unterschied ist das es aus unterschiedlichen Tabellen jetzt alles aus nur einem Contentpool gefischt wird

Es ist eben kein Vorteil alles in einen Topf zu werfen und dann immer wieder alles zu durchsuchen, wenn man nur einen bestimmten Teil davon überhaupt durchsuchen müsste, wenn man denn einen anständigen Entwurf gewählt hätte. Zumal er ja offensichtlich mit eigenen Contenttypen experimentiert hatte und dann meinte, er würde doppelten Code schreiben. Ich weiß nicht, ob er es nicht auch mit Vererbung hätte versuchen können...

 

[Haddawas]

mal vorne weg, hast du schon mal eine PHP datei offen gehabt? ganz ehrlich, ich zweifle gerade schwer daran wenn ich deine Antwort zu Blogs so lese

zu den Rechten, lies meine Frage - natürlich meine ich auch alles - denkst du nur weil jeder User seine Privacy selbst einstellt wird das einfacher zu verwalten, oder wie?

wenn die Blogeinträge von A zu B sollen, werden diese beiden (wenn nicht direkt ausgewählt) anhand der Blogid (A), und dann letztlich anhand der Eintragsids zu B übertragen, dabei ist es irrelevant ob es 10 oder eine eine Mio Beiträge in der Tabelle sind, die Mechanik ist die selbe und ist das selbe als wenn du einen Thread von Forum A zu B verschiebst, oder Beiträge abtrennst und einen neuen Thread daraus machst
(ok letztlich wird etwas ein zwei IDs gesucht, aber nicht Volltext nach UserA und ist das nicht der Sinn einer DB das die das schnell auch mit großen Datenmengen kann?)
das die Blogs dann z.b. bei "Foren" in einer separaten Tabelle Tabelle liegen und als solche behandelt werden ist klar
(nur für den Fall das jetzt jemand fälschlicher weise denkt mein Ansinnen war alles in eine Tabelle zu packen - es geht nur um gleiche Contenttypen wie Beiträge = Kommentare = Artikel = Zusatztexte)

Galeriebild, dann denk mal drüber nach wo hier die parallelen liegen oder auch nicht
Galeriebild + kurzer Text == Beitrag mit einem Dateianhang
Kommentare == Kommentare
ich sehe da keinen Unterschied zwischen einem Thread und einem Galeriebild das man bewerten kann, das Bild wird natürlich als der Contenttyp gespeichert welcher er ist (Dateianhang) und nicht als base64 im Textfeld (s0 schlau solltet ihr Profiprogrammierer schon sein)

wegen dem Aufwand einzelne Bereiche zu durchsuchen gebe ich dir recht, aber in aller Regel durchsucht man nun mal alles und pickt sich die Rosinen heraus
außerdem muss man ja nicht wie hinz und kunz den Volltextindex auf den Beitragstext verwenden, man könnte eigene Suchtabellen (ala vB4, die werfen da übrigens alles zusammen) verwenden, oder eigenständige Suchindexe wie Sphinx oder das Zeug das XF eh vertreibt was einen eigenen Dienst mitbringt verwenden. wie die das organisieren kann ich jetzt nicht beantworten aber da es eh ein eigenständiges system ist hat man hier wohl einige Möglichkeiten

von wegen "Foren für alles und jeden", ich verwende den Begriff Foren nur weil mir da jetzt kein besserer Einfällt und wohl jeder damit was anfangen kann - ihr könnt es auch als node oder Rechtebasis übersetzen
wenn man ein Rechtesystem schon von beginn an so konzipiert große Varianz zu verwalten dürfte das auch kein Ding sein und evtl profitieren davon auch die Foren zum schluß weil man beispielsweise einzelne Threads individuell mit rechten ausstatten könnte
und der kleinste gemeinsame nenner ist hier wohl einfach das Userprofil wenn man von Profilnachrichten/Freunden/Kreisen und weiß der geier welchen variablen ausgeht die es zu berücksichtigen gibt
alles andere ist da doch nur noch ein Kinderspiel (threads haben keine Freunde - noch nicht)

 

[ragtek]

von wegen "Foren für alles und jeden", ich verwende den Begriff Foren nur weil mir da jetzt kein besserer Einfällt und wohl jeder damit was anfangen kann - ihr könnt es auch als node oder Rechtebasis übersetzen
wenn man ein Rechtesystem schon von beginn an so konzipiert große Varianz zu verwalten dürfte das auch kein Ding sein und evtl profitieren davon auch die Foren zum schluß weil man beispielsweise einzelne Threads individuell mit rechten ausstatten könnte

Ja und genau darum geht es mir ja (ich glaube langsam, das wir einandand vorbeireden )

xf bietet hier von Haus aus ein System an, mit dem VERSCHIEDENE node typen (und deren zugehörigen Rechten) haben kann, die mehr oder weniger container für die verschiedenen content typen sind
und das ganze hat IMO schon seinen sinn... (wieso sollte der forum link node typ die gleichen Felder haben, wie ein normales Forum, das eben last user id, last post id usw hat, aber keinen weiterleitungslink benötigt.... oder wieso sollte das benutzerrecht zum fotos hochladen / alben erstellen => "kann thread erstellen" lauten)


ABER, da ich glaube das man hier aneinand vorbeiredet, klinke ich mich aus und warte auf das gute Produkt...
Wie gesagt, traue guitar sehr viel zu, also werden wir vlt alle pos. überrascht sein

 

[Haddawas]

gut genau der Typ unterscheidet sich jetzt wirklich, andererseits könnte man das Feld anderweitig nutzen bei einem Thread, z.b. wenn man jetzt von einem Bild spricht könnte dort die Vorschaugrafik verlinkt werden, bzw das Bild an sich - bzw würde es die Möglichkeit bieten eines der Dateianhänge (wenn vorhanden) eben als Preview einzubinden
wobei das wohl eine ziemliche Last bedeuten würde (haben aber schon welche als Addon umgesetzt) ich würde aber eher thumbs im filesystem in dem Fall bevorzugen - aber wenn man es sicher haben möchte, kommt man auch bei einer Galerie nicht drum herum das durch PHP zu lösen

 

[principia]

ABER, da ich glaube das man hier aneinand vorbeiredet, klinke ich mich aus und warte auf das gute Produkt...
Wie gesagt, traue guitar sehr viel zu, also werden wir vlt alle pos. überrascht sein

So sehe ich das auch. Wenn guiltar so gut ist, wie du sagst (ich bin ja ahnungslos) , dann wird er sich schon darüber Gedanken gemacht haben.

 

[Hatsu]

[...]wenn die Blogeinträge von A zu B sollen, werden diese beiden (wenn nicht direkt ausgewählt) anhand der Blogid (A), und dann letztlich anhand der Eintragsids zu B übertragen, dabei ist es irrelevant ob es 10 oder eine eine Mio Beiträge in der Tabelle sind, die Mechanik ist die selbe und ist das selbe als wenn du einen Thread von Forum A zu B verschiebst, oder Beiträge abtrennst und einen neuen Thread daraus machst[...]

Ach wirklich? Es dauert also genauso lange 2 Datensätze in 10 zu finden wie in 1 Million? Danke für Deine erhellenden Worte. Das wusste ich wirklich nicht

Erklär doch mal bitte was die Programmiersprache PHP mit einem Datenmodell gemein haben soll? Ich habe meine Datenmodelle bisher völlig ohne PHP ausgearbeitet, aber hey, ich lerne gerne dazu. Oder war der erste Satz nur eine plumpe Provokation um vom Rest Deines Beitrages abzulenken?

Ich habe über das Galeriebild nachgedacht und ich bleibe dabei, es ist und wird kein Thread draus.

Da es ragtek, Walter und Alluidh ähnlich sehen wie ich, kann ich nicht so ganz falsch liegen.

 

[Haddawas]

also wenn ich das in der mir zur Verfügung stehenden DB versuche

1 aus 882.924, die Abfrage dauerte 0.0003 sek.
1 aus    105, die Abfrage dauerte 0.0004 sek.
1 aus 910.932, die Abfrage dauerte 0.0003 sek.
1 aus 17.928.773, die Abfrage dauerte 0.0004 sek.

die letzte hatte dazu drei AND Anweisungen, die anderen waren schlicht where id = x

keine Ahnung mit was für spielzeug du arbeitest, aber Mysql ist wohl wenig beeindruckt von großen Tabellen

also lass das gejammer, oder untermauer das mit ein paar handfesten zahlen, große Reden schwingen bringen uns wenig weiter

 

[Hatsu]

Im Livebetrieb mit mehr als zwei Benutzern und nicht auf localhost ist das sicherlich beeindruckend. Stimmt.

 

[Haddawas]

Livebetrieb auf nem vServer, rennt aktuell nur ein vb3 mit 160Usern online und dazu piwik drauf (von meiner Seite)
was da an Hardware drunter steckt und ob/welche anderen Gastrechner weis ich leider nicht

ein neuladen der Abfrage wurde immer mit 0.0001 sek. quittiert, was wohl dem Cache geschuldet ist

 

[Hatsu]

Wie viele JOINS?

 

[Haddawas]

einfach nur Select * from XY where id= x
bzw
in der Suchfeldtabelle Select * from XY where id= x and fo = y and ob = z and ar = x

aber bei einem Update benutzt man ja auch kein Join, oder doch? also bezogen auf Blog eintrag x von user a auf b

außerdem ist das eben die Livetabelle des Forums, da passende Queries zusammen zu schustern die auf unterschiedlichen Tabellen laufen war mir dann doch zuviel arbeit

außer bei der postindex tabelle mit den 18 Mio war auf dem ID feld immer ein Index, die post hat nur auf einem einen Index

 

[Hatsu]

Ich muss Dich jetzt bitten den Beitrag bis zum Schluss zu lesen bevor Du auf antworten klickst, denn ich hol ein wenig aus um mich verständlich zu machen. Nochmal zur Klarstellung. Wenn ich von Suche rede, dann meine ich jede Aktion, die eine Suche erfordert. Das ist auch der Klick auf ein Thema und es wird nach allen Beiträgen dieses Themas gesucht und die Ergebnismenge wird mir angezeigt.

Schau, ich will weder den Programmierer als schlecht beschimpfen noch behaupten dass das, was sie machen alles scheiße ist. Es ist aber meine Meinung, dass verschiedene Dinge nicht in einen Topf geworfen werden sollten.

Ein Verschieben allein ist auch mehr als nur das Update. Ich muss vorher schon wissen was ich updaten soll und die Suche danach hat eventuell schon JOINS, je nachdem aus welcher Situation heraus das Update geschehen soll.

Der Anhang zeigt beispielhaft die Bestandteile der Posttabelle von xf. Wie man sieht sind sowohl die Benutzer-ID als auch der Benutzername in der Tabelle hinterlegt. Grundsätzlich ist das Redundanz, es würde die ID reichen. Wohl aus Performancegründen (um sich JOIN zu sparen?) haben sich Kier und Mike für ein bisschen Redundanz entschieden. Das ist nur beispielhaft und wird auch in anderen Tabellen von xf (und bei anderen Anbietern) so gehandhabt, weil wohl halt oft nach Nutzernamen gesucht wird.

Wenn ich nun aber hergehe und eigene Inhaltstypen erstelle und deren einzigartige Attribute in eine andere Tabelle auslagere, mache ich das genaue Gegenteil (JOIN betreffend). Warum lagert man dann nicht gleich den gesamten Inhaltstypen aus? xf ist so konzipiert, dass ich Likes, Report usw. auch in eigenen Inhaltstypen verwenden kann, ich muss es nur einbauen. ragtek hat's weiter oben gezeigt, dass das geht. Diese Funktionalität ist das urgeigene Interesse von Kier und Mike, denn sie wollen ja irgendwann Addons verkaufen.

Egal wie man es dreht und wendet, ich muss die Zusatzinformationen (isses Artikel, Blog, Galeriebild etc.) irgendwo hinterlegen. Entweder als zusätzliches Tabellenfeld + Tabelle oder mit einer Zwischentabelle -> JOIN.

Mir sträuben sich bei dem Ansatz einfach die Haare, wohl auch deshalb, weil laut ragtek der Junge gut ist und er es auch besser weiß(er hat's ja probiert).

 

[Haddawas]

ich sage ja nicht das wenig Einträge vielleicht performanter sind, die Frage ist eher ab welcher Zahl wird es wirklich relevant und messbar ob man jetzt aus 100, 1000 oder 100Mio einträgen einzelne herausfischt
und macht es wirklich einen Unterschied am Ende der Ausgabe wenn man eh den ganzen Content durchen muss?
einen großer Anteil an der Verarbeitungsdauer trägt hierbei IMO auch wieviele Treffer es gibt, da diese ja dann für sich wieder nachfolgend sortiert werden müssen, aber ab einen bestimmten Punkt ist das dann irrelevant ob diese Treffer allein oder mit unzähligen anderen in einer Tabelle waren, weil das IMO eh im Speicher geschieht

Eurer Logik zufolge wäre es a eigentlich ratsam/besser für jedes einzelne Forum eine Tabelle zu erstellen, was aber schon wegen der nicht fortlaufenden ID nicht klappen kann und deswegen wohl auch nie in frage kommt. das Problem haben wir so im allgemeinen auch bei unterschiedlichen Contenttypen.
um also eine umfassende Suche auf alle Typen zu gestalten muss ich jeden Contenttyp einzeln abfragen, und die Ergebnisse (welche man aus performancegründen allgemein zwischenspeichert) dann via Join mit der Deko ausgeben
jetzt kann man das aber nicht übergreifend machen weil die IDs doppelt sind bzw eh anders betitelt dafür müssen die Joins auf gemeinsame Daten wie UserName ID und anderen Kleinkram hier zwangsläufig mehrfach abgefragt werden
somit gibt es eigentlich mehr overhead, das kaschiert man dann mit einer ebenfalls nach content getrennten Darstellung - schaut gut aus ist aber eigentlich ein prozessbedingtes Problem das sich anderes nicht lösen lässt wenn man es in der Skriptsprache nicht selbst wieder zusammenmischt, die DB kann es IMO nicht

die von dir angesprochene Redundanz der Datenhaltung ist doch eigentlich was du mit den JOINs schon gesagt hast, warum wegen einer lapidaren Information (Name als Text) einen Join ausführen (im gegenzug sieht man in der DB auch gleich den namen, zumal wenn ein Gast postet du den Namen eh hinschreiben musst, wenn du die Info nicht auch noch bei UserID 0, dann aus der Posttabelle fischen willst (IF statements gibts ja IMO auch direkt im Query)

ich verstehe durchaus was ihr sagen wollt, aber ich kann nach wie vor keinen passblen grund für mich ausmachen warum es so gemacht wird wie man es macht - außer vielleicht weil man das schon immer so gemacht hat - was aber vielleicht auch daran liegt das bisher die meisten Anbieter nur den Core geliefert haben und das andere Zeug meist Optional war, entsprechend macht sich über gemeinsame Tabellen keiner wirklich einen kopf weil es nicht seine Baustelle ist

bei Querys ist zudem was ich bisher erlebt haben wirklich Können gefragt, ich habe schon erlebt das ein Query 10 sec. gebraucht hat, wenn man dann einen (a.id=b.id) einfügte war das in ein paar ms gegessen. da gebe ich zu wird es mit zunehmender komplexität schwerer aber deswegen haben Programmierer das ja auch hoffentlich gelernt und wissen was die tun statt dem Tria&Error-idioten wie mir, der es höchsten zufällig herausfindet oder irgendwo abschauen kann

vielleicht könnte man diese DB Diskussion vom Addon mal abtrennen?!

 

[Hatsu]

die von dir angesprochene Redundanz der Datenhaltung ist doch eigentlich was du mit den JOINs schon gesagt hast, warum wegen einer lapidaren Information (Name als Text) einen Join ausführen (im gegenzug sieht man in der DB auch gleich den namen, zumal wenn ein Gast postet du den Namen eh hinschreiben musst, wenn du die Info nicht auch noch bei UserID 0, dann aus der Posttabelle fischen willst (IF statements gibts ja IMO auch direkt im Query)

Wenn man die Post-Tabelle für Inhalte nutzt, die kein Post sind, musst Du joinen. Es sei denn Du erweiterst die Post-Tabelle. Das Bild von der Post-Tabelle ist komplett, ich hab da nix abgeschnitten. Für andere Inhalte fehlen da noch Merkmale, also entweder neue Tabelle und Relation oder man fügt neue Felder ein. Kein Join aber viele leere neue Felder.

Die Content-übergreifende Suche, die Du ansprichst, ist mit der von mir bevorzugten Lösung nur schlecht möglich. Also man kann nicht in einer Darstellung allen neuen Content ansehen. Da ist die Eintopflösung wieder besser IPS hat das mal versucht und aus Performancegründen schnell wieder sein lassen. Es wird momentan so gelöst, dass jeder Contenttyp einen eigenen Tab hat. Für den einen ist dies ein Nachteil. Es stellt sich allerdings die Frage, ob man das wirklich braucht oder ob das über das Alertsystem und die Nutzereinstellungen nicht besser gelöst wäre.
Ich zitiere mal deren Probleme:

We attempted something like this with 3.0.0 (prior to release) and it was a performance nightmare. Effectively, every insert into a table (posts, downloads, gallery, etc.) required an insert into another table (that would be used for searching, but could be used for other purposes - e.g. content spy type applications), and that table grew exponentially huge very quickly. The sheer size and number of records, and the difficulty maintaining it consistently across applications, created resource and functionality issues.
Searching multiple database tables and putting the results into one view just isn't feasible, due to pagination. You need a central table, or you need to use a tool like Sphinx that can search multiple indexes simultaneously.
There are a lot of technical challenges to this sort of functionality, which is why it isn't a feature ... yet.

Sie wollten eine Tabelle nur für die "Was ist neu"-Sache machen. Also für einen bestimmten Zweck und sie haben es dann sein lassen. Ich kann mir nicht vorstellen, dass die Eintabellenlösung in xf da dann viel besser abschneiden wird. Wird man sehen.

ich verstehe durchaus was ihr sagen wollt, aber ich kann nach wie vor keinen passblen grund für mich ausmachen warum es so gemacht wird wie man es macht - außer vielleicht weil man das schon immer so gemacht hat - was aber vielleicht auch daran liegt das bisher die meisten Anbieter nur den Core geliefert haben und das andere Zeug meist Optional war, entsprechend macht sich über gemeinsame Tabellen keiner wirklich einen kopf weil es nicht seine Baustelle ist

Schon immer so war es sicher nicht, denn vor PHP5 war die Möglichkeit dazu gar nicht so einfach. Ich war früher eher immer auf Deinem Weg, bis ich dann was von Vererbung gehört hatte (das zugrundeliegende Framework muss es natürlich bieten). Ums Kurz zu machen: Ich hab mir also alles geklaut äh vererbt was ich brauchen kann und das was nicht brauchbar war überschrieben. Dann fiel mir auf, wieso zwänge ich es denn in das alte geflickte Korsett(Tabelle) und spendier ihm nicht ne neue?

Es ist natürlich auch eine Ermessenssache. Nehmen wir an ich baue eine Funktionalität ein, die lediglich nur ein neues Feld benötigt. Dann mach ich das natürlich. Sobald es aber mehr wird muss man dann schon abwägen.

 

[ragtek]

so
also auch wenn ich nach wie vor dagegen bin, habe ich sein Konzept aus Bequemlichkeit mal für ein Artikel,Blog,Download Kategorie,Whatever System umgesetzt und es gefällts mir, da es den codingaufwand erheblich reduziert


Jedes Forum kann nun Forum,Artikel,Blog,Download Kategorie sein und je nachdem werden dann zusätzliche Input Felder beim "Thread erstellen" angezeigt und die Thread Ausgabe manipuliert.

Und die Joins sind ja auch nicht drastisch, DA es pro Forum sowieso nur den einen weiteren gibt (zur artikel,blog,whatever tabelle, die die zusätzlichen Daten enthält)

 

[ragtek]

backend schaut dann in etwa so aus

(Bei den Optionen ist der Screenshot etwas älter, der Bug mit den vertauschten tabs wurde schon behoben und es sind paar neue Optionen dazugekommen^^)

Mehr Infos gibt es in paar Tagen vom Vertriebs & Support Partner