Nachtrag in Sachen Kategorieproblem

idea-tec
Beiträge: 1242
Registriert: Do 19. Sep 2002, 14:41
Wohnort: Dichtelbach
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von idea-tec » Fr 19. Jun 2009, 14:11

Dodger77 hat geschrieben:Aber diverse Module tun dies halt ("ORDER BY idtree"), ob das jetzt sinnvoll und notwendig sein mag oder nicht
Naja, ich hab das auch schon gemacht (sowohl idtree als auch level), weil es halt da ist und weil es, je nach anwendung, nicht wirklich sinnvoll aber halt einfach ist.

wenn ich also von mir ausgehe, dann unterstützen wir lediglich die faulheit der programmierer ;-)
MfG, Karsten
Nicht Können bedeutet nicht, dass man etwas nicht beherrscht, sondern lediglich, dass man sich nicht traut es zu tun ;-)
| Internet | Ihr Logo deutschlandweit auf T-Shirts |
Diplomatie: Jemanden so in die Hölle zu schicken, dass er sich auf die Reise freut!!! ;-)

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Fr 19. Jun 2009, 14:29

Dodger77 hat geschrieben:Ich kann die gar nicht brauchen. Aber diverse Module tun dies halt ("ORDER BY idtree"), ob das jetzt sinnvoll und notwendig sein mag oder nicht.
ach so, jetzt verstehe ich das erst richtig. die idtree ist kein primärschlüssel - worauf der name eigentlich hindeuten würde - sondern eine erneute aufbereitung der reihenfolge. ok, dann müsste man das vielleicht noch etwas erhalten. die reihenfolge wird also zur sicherheit :roll: dreifach gespeichert:
  • in der postid
  • in der preid
  • in der idtree
geniale sache. das müsste man vielleicht mal in einem tech-paper ausführen, damit andere, die diese idee noch nicht gehabt haben, das auch machen können. keine einfache, sondern gleich eine dreifache redundanz und noch dazu verteilt auf mehrere tabellen. das nenne ich nun mal 4fb-te-normalform... :lol:

aber immerhin verstehe ich jetzt, weshalb die con_cat_tree - mindestens mittelfristig - noch benötigt wird. im backend wird das aber nicht verwendet, oder? nur noch in - sagen wir mal - veralteten modulen?
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

emergence
Beiträge: 10641
Registriert: Mo 28. Jul 2003, 12:49
Wohnort: Austria
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von emergence » Fr 19. Jun 2009, 15:21

doch das wird im backend verwendet...
durchsuche doch einfach mal den quellcode nach 'idtree'
das erklärt mir nun auch die merkwürdigkeit mancher deiner sql abfragen...

ein direktes auslesen der reihenfolge via postid oder preid ist ohne eine zusätzliche tabelle wie in diesem fall cat_tree nicht wirklich einfach möglich... das mit dem level in der tree ist einfach nur eine zusätzliche option nach der man selektieren kann... (und nicht muss)

das die logik zum teil in den php teil gelagert wurde stört mich nicht wirklich... das es unübersichtlich gemacht ist schon weit eher...
alles in den sql teil zu verlegen ist eine variante die nicht einfacher sein muss...
da muss man halt ein sql experte sein um das zu verstehen... ;-)

normalisierung ist zu einem grossteil wünschenswert aber nicht immer notwendig...

ad. rtl und lft werte
con_cat würde ich nicht nehmen..
ich würde das in die cat_tree reinbauen... das habe ich aber auch schon mal geschrieben...
dann hat die tabelle wenigstens ihren namen verdient... und das sogar mit rückwärtskompatibilität...

ad. function strMoveUpCategory
ähm, nicht wirklich jetzt genau angesehen...
aber wenn das element das bewegt werden soll bereits das erste ist, wieso gibt es dann noch ein update query ?
da muss dann nichts mehr upgedatet werden...
*** make your own tools (wishlist :: thx)

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Fr 19. Jun 2009, 16:32

emergence hat geschrieben:aber wenn das element das bewegt werden soll bereits das erste ist, wieso gibt es dann noch ein update query ?
da muss dann nichts mehr upgedatet werden...
es werden drei fälle unterschieden:
  • kategorien in der mitte (normalfall)
  • zweitoberste kategorie (da es nach der verschiebung keine kategorie gibt, deren postid angepasst werden würde)
  • unterste kategorie (da es kein folgendes element gibt, dessen preid angepasst werden müsste)
die oberste kategorie ist von einer verschiebung auch dann nicht betroffen, wenn ein solcher query abgesetzt werden müsste, da die resultatemenge null ist.

ich habe die neuerstellung der idtree gekippt, da ich die bedeutung des primärschlüssels nicht richtig eingeschätzt habe, da dieser ja kein primärschlüssel, sondern ein sortiermerkmal ist. das müsste man wieder ergänzen, da sonst die con_cat_tree nicht stimmt.

die auslagerung in eine sperate tabelle (con_cat_tree) kann man machen. allerdings ergeben sich dadurch eigentlich keine vorteile, da diese ja streng 1 : 1 verknüpft ist. aber man müsste eigentlich die idcat zum primärschlüssel machen, da dieser genau nur einmal vorkommen kann. gleichzeitig ist dann die akatualisierung der idtree einfacher, da während des updates mehrfachauftreten der idtree nicht mehr stören würde.

die bündelung in einen query hat vor allem zwei vorteile:

a) es ist erheblich schneller
b) ein abbruch stört nicht, da die aktion ganz oder gar nicht vorgenommen worden ist.

ich werde mich auf ausdrücklichen wunsch von 4fb dazu jetzt - mindestens hier - nicht mehr gross äussern. mir ist bedeutet worden, dass mein input nicht nur nicht berücksichtigt werden würde, sondern dass eine weitere diksussion nicht gewünscht sei. es ist mir zwar völlig egal, was 4fb denkt. der wink mit dem betonpfeiler ist jedoch so eindeutig, dass alles weitere reine zeitvergäudung wäre. wer sich also wundert, wieso die community von contenido nicht stärker ist, der kriegt von 4fb zuweilen eine antwort.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

rbi
Beiträge: 95
Registriert: Do 27. Sep 2007, 21:33
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von rbi » Fr 19. Jun 2009, 16:59

kummer hat geschrieben:ich werde mich auf ausdrücklichen wunsch von 4fb dazu jetzt - mindestens hier - nicht mehr gross äussern. mir ist bedeutet worden, dass mein input nicht nur nicht berücksichtigt werden würde, sondern dass eine weitere diksussion nicht gewünscht sei. es ist mir zwar völlig egal, was 4fb denkt. der wink mit dem betonpfeiler ist jedoch so eindeutig, dass alles weitere reine zeitvergäudung wäre. wer sich also wundert, wieso die community von contenido nicht stärker ist, der kriegt von 4fb zuweilen eine antwort.
Es ist wirklich schade, dass du alles, was ich dir (in diesem Fall in einer PM) schreibe, falsch verstehen willst.
Ich habe geschrieben, was >ich< denke und dass >ich< der Meinung bin, dass viele der geführten Diskussionen nicht zielführend sind.
Das war gewiss kein Maulkorb, das will ich hier mal klarstellen. Mehr dann in einer PM.
hey, ich bin nicht mehr rot!

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Fr 19. Jun 2009, 17:22

rbi hat geschrieben:Es ist wirklich schade, dass du alles, was ich dir (in diesem Fall in einer PM) schreibe, falsch verstehen willst.
Ich habe geschrieben, was >ich< denke und dass >ich< der Meinung bin, dass viele der geführten Diskussionen nicht zielführend sind.
Das war gewiss kein Maulkorb, das will ich hier mal klarstellen. Mehr dann in einer PM.
ne ne, die botschaft steckt zuweilen auch zwischen den zeilen. gewünscht - soviel steht fest - ist es nicht. integriert wird's auch nichts. kein beinbruch für mich; für meine kunden kann ich ja immer noch machen, was gut für sie ist. insofern ist es für mich kein schaden.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

rbi
Beiträge: 95
Registriert: Do 27. Sep 2007, 21:33
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von rbi » Fr 19. Jun 2009, 18:58

Nun dann. Wenn du das aus/zwischen meinen Zeilen lesen magst, so darfst du das. Gemeint war allerdings das, was ich in Worten schrieb.
Ich will doch hier nicht den zwischen den Zeilen schreibenden Foren-Sheriff spielen. ;) Deshalb bin ich jetzt auch lieber wieder ruhig.
hey, ich bin nicht mehr rot!

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Fr 19. Jun 2009, 19:03

@rbi: ich habe dir ja einen möglichen ansatz geschildert. wenn man nun was tun will, müsste man es angehen. der anfang ist ja in 1 minute getan... ;-)
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von Oldperl » Sa 20. Jun 2009, 12:58

Soderle, nun muß ich doch auch noch einmal was dazu sagen. Ich denke nicht das nested sets das Problem alleine lösen werden, sie werden es für eine gewisse Zeit kaschieren, denn es liegt meiner Meinung nach nicht primär am Umgang mit den Kategorien. Es liegt noch an weit mehr warum connects und queries das Ganze verlangsamen.
Und auch daher ist eine Integration von nested sets nicht mal schnell in einer Minute gemacht, sondern das wäre nur sinnvoll, wenn dabei auch die anderen Baustellen im Kategoriebereich gleich mit abgearbeitet werden.

Um das mal zu konkretisieren habe ich mich die letzten Tage mal ein paar Stunden damit beschäftigt den Ablauf in der includes.str_overview.php aufzudröseln. Mal ganz davon abgesehen, das ich dabei noch über ein paar Bugs gestolpert bin, die ich, wenn geprüft, im Bereich Bugs einstellen werde, habe ich auch ein paar Versuche zur Auslastung, gerade der DB-Anbindung, gefahren.

Vorraussetzung:
Contenido 4.8.12
PHP 5.x
MySQL 5
das Ganze auf nem lokalen Linuxserver
Demomandant mit 1 zusätzlichen Kategorie (=35 Kat)

1. Durchlauf (ohne Änderungen)
Building this page (excluding contenido includes) took: 1.2401649951935 seconds
Building the complete page took: 2.5811569690704 seconds
Include memory usage: 1.75 MB
Complete memory usage: 8.44 MB
Amount of DB connects: 102
Amount of DB selects: 102
Amount of DB queries: 388
2. Durchlauf
Hier wurde nur im Plugin workflow die CEC-Anbindung zum Kategoriebereich in der config.plugin.php auskommentiert

Code: Alles auswählen

$_cecRegistry->addChainFunction("Contenido.CategoryList.Columns", "piworkflowCategoryColumns");
$_cecRegistry->addChainFunction("Contenido.CategoryList.RenderColumn", "piworkflowCategoryRenderColumn");
Das Ergebnis sieht dann so aus
Building this page (excluding contenido includes) took: 1.0823950767517 seconds
Building the complete page took: 2.4627871513367 seconds
Include memory usage: 1.64 MB
Complete memory usage: 8.33 MB
Amount of DB connects: 30
Amount of DB selects: 30
Amount of DB queries: 320
Für jede Kat werden min. 2 Queries abgesetzt. Und so geht es in weiteren Bereichen weiter und die Queries summieren sich.
Auch kommt es durch den klassischen All-In-One Aufbau der Datei zu Abfragen, die man einmal zentral mit einem Query in ein Array machen könnte und Anfragen dazu im weiteren Verlauf daraus bedienen sollte.

Zusammenfassend denke ich, man sollte den gesamten Bereich wirklich mal "Neu" machen, und wenn dabei nested sets mit integriert werden fände ich das auch klasse. Man muss sich aber auch um Pagination Gedanken machen, da egal wie man es löst, irgendwann auch die Resourcen (Speicher, Zeit) erschöpft sind.

Ich werde nun trotzdem erst mal an den vorhandenen Dateien arbeiten, da eine andere Lösung IMO nicht von jetzt auf gleich zu erstellen ist.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Mo 22. Jun 2009, 08:12

da hast du recht, ortwin. nested sets lösen per se keine probleme. das habe ich so auch nicht behauptet. ich bin der meinung, es ist die beste variante der abbildung der hierarchie, insbesondere, wenn eine reihenfolge innerhalb der kategorien gewünscht ist. wir haben das klassische szenario weniger aktualisierungen und relativ vieler abfragen der hierarchie. dabei sind verschachtelte mengen hinsichtlich leistung ideal. ausserdem ist der normalisierungsgrad ideal.

worauf ich eigentlich abzielte war, die anzahl abfragen und verbindungen zu reduzieren. der einsatz mehrerer verbindungen ist auf zwei faktoren zurück zu führen:
  1. verwendung von abfragen, die lediglich eine teilmenge liefern und unterabfragen erorderlich machen
  2. und auf die abstraktionsschicht, welche die resultatemenge nicht auf einmal auf den webserver zieht, sondern erst bei der iteration (verwaltung der resultatemenge in mysql)
alleine durch die reduktion der abfragen lassen sich beide probleme lösen und es wird nunmehr nur eine verbindung benötigt. die einzelnen abfragen mögen dabei komplexer erscheinen, beinhalten selber jedoch die notwendigen ausschlusskriterien und reduzieren damit die wahrscheinlichkeit von fehlern bei der ausführung.

insgesamt haben wir ein problem vorliegen, dass beim vorliegenden normalisierungsgrad fast unvermeidlich ist. wir bilden die hierarchie doppelt (parentid und level), die reihenfolge jedoch dreifach ab (preid, postid und idtree). insbesondere die idtree ist dabei problematisch, da es sich dabei aktuell um einen primärschlüssel handelt, obwohl die idcat alleine eindeutig wäre. hier zum beispiel bringt die löschung des primary key index auf die idtree und einführung eines entsprechenden indizes für die idcat bereits eine verbesserung. aber solange eine solche redundanz besteht, kann der datenbestand grundsätzlich je nach betrachtungsweise gültig und auch ungültig sein.

ich habe rbi folgenden vorschlag gemacht:
ich hätte vorgeschlagen, wie folgt vorzugehen (notabene für eine nächste version):
  1. integration von lft und rgt in die con_cat (zunächst leer, einfach mit die felder vorhanden sind)
  2. reduktion der methoden zur verschiebung einzelner kategorien oder ästen auf das unvermeidliche mass an abfragen unter verwendung nur einer verbindung
  3. berücksichtigung von lft und rgt (dabei spielt es zunächst keine rolle, ob diese einen wert enthalten oder nicht) und die komplexität steigt kaum
  4. berücksichtigung von lft und rgt beim einfügen und löschen von kategorien
  5. dann die con_cat_tree auf basis einer abfrage unter berücksichtigung der nested sets aufbauen (auch das geht dann mit einer abfrage, inkl. level und reihenfolge)
das schöne daran ist, dass während diesem vorgehen zu keinem zeitpunkt andere systemteile tangiert sind. alles läuft genau so wie vorher. die postid, wie auch die preid, die idtree und das level: alles ist noch da. dann könnte man (step by step):
  • zunächst beim auslesen der kategorien die nested sets (lft und rgt) verwenden.
  • wenn dann nirgends mehr preid und postid verwendet wird, kann man diese beiden merkmale entfernen
  • die con_cat_tree ist zwar nunmehr überflüssig (da die abfrage mit nested sets schneller sein wird), stört jedoch nicht und kann deshalb erhalten bleiben, bis eine angemessene frist verstrichen ist und und die tabelle von keinen neueren modulen mehr benötigt wird.
  • dann kann auch diese gelöscht werden.
damit ist ein unbefriedigender zustand in einen ordentlichen zustand überführt. neben der zeiterparnis, die resultiert (sowohl im backend wie vor allem im frontend) wird der höhere normalisierungsgrad die probleme vermeiden, die derzeit auftreten.
so schlimm, wie sich der umbau anhört, ist er jedoch gar nicht. zunächst bleibt ja die bisherige hierarchie erhalten wie auch die con_cat_tree (das heisst, alle abfragestellen funktionieren weiterhin). die bildung der con_cat_tree benötigt nunmehr nur noch eine einzelne select-into-abfrage und wird folgerichtig immer konqurent sein zum übrigen datenbestand.

und damit wäre dann das problem tatsächlich gelöst. die vermutung nämlich, dass hier lediglich ein bug vorliegen würde, ist nicht ganz zutreffend. wir haben ein lehrbuchbeispiel, wie es nicht sein soll und von dem bekannt ist, dass die fehlerwahrscheinlichkeit sehr gross ist.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

conradius
Beiträge: 168
Registriert: Di 19. Jul 2005, 11:52
Wohnort: Wabern (Bern/CH)
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von conradius » Mo 22. Jun 2009, 16:37

Bravo! Und was meint rbi dazu?

Gruss
Conrad

kummer
Beiträge: 2423
Registriert: Do 6. Mai 2004, 09:17
Wohnort: Bern, Schweiz
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von kummer » Mo 22. Jun 2009, 17:00

rbi hat sich dazu vorerst nur in einer pm geäussert. ich möchte einer stellungnahme an dieser stelle nicht vorgreifen. ohne koordination wird es wohl nicht gehen; wie die weiteren schritte aussehen, die konkret geplant sind, habe ich keine ahnung. ich hoffe, rbi äussert sich dazu in diesem oder einem anderen thread.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)

rbi
Beiträge: 95
Registriert: Do 27. Sep 2007, 21:33
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von rbi » Di 23. Jun 2009, 11:03

Ich habe es intern weitergegeben, ich bin aber nicht in der Position, darüber zu entscheiden, was letztlich damit passiert.
hey, ich bin nicht mehr rot!

former
Beiträge: 27
Registriert: So 2. Jul 2006, 19:16
Wohnort: Offenbach
Kontaktdaten:

Re: Nachtrag in Sachen Kategorieproblem

Beitrag von former » Mi 9. Sep 2009, 10:05

Servus!

Da bei mir gestern auch alle Kategorien eines Mandanten verschwunden sind (22 Mandanten, 28 Sprachen, Con. 4.6.23 --> Update auf 4.8.12) wollte ich mal kurz nachhören ob sich hier schon etwas getan hat. Bzw. wo ich das Problem weiter verfolgen kann. Habe leider keinen Thread gefunden.

Schöne Grüße
Christian
CMS-Version: Contenido Ver. 4.8.12 -- Ver. 4.8.15
------------------------------------------------------------------------------------------------------------------
PalmenSamen.com - Palmen und Exotische Samen
SamenWunder.de - Exotische und seltene Samen

Gesperrt