da kommt so einiges zusammen. die anzahl queries hat - wie du später auch ausführst - tatsächlich einfluss auf das problem. insbesondere stört es die eingrenzung der ursache. weil eine ursache ist bekannt und klar: ohne übersicht wird es mehr fehler geben als mit.emergence hat geschrieben:hmm... mir fehlt mittlerweile die zeit(oder auch lust) hier im forum support zu geben...
dann zur frage der patches: logisch braucht es patches. aber immer nur zwischen zwei versionen. insofern stehe ich absolut zu meiner aussage: patches werden auf dauer das problem nicht lösen, weil sie eben nicht auf die ursache eingehen. und die ursache ist eben nicht in einem einfachen programmierfehler zu suchen , sondern in einem design-problem. schlechte normalisierung wird solche probleme verursachen, da mit programmfehlern stets zu rechnen ist. bei guter normalisierung, verwendung von constraints und der bildung von transaktionen bleiben diese probleme aus. auch das ist fakt.
ich bin auch nicht gegen patches. aber das problem besteht eben nicht erst in der 4.8.12, sondern war spätestens seit der version 4.8.11 bekannt. und ähnliche probleme waren schon vorher festzustellen, jedoch mit einer einfachen möglichkeit, die daten wieder richtig zu stellen. und dieses problem bestand sogar schon in den 4.6er-versionen.
ich habe auch nie daran gedacht, die nested sets als patch einzubauen. es geht darum aufzuzeigen, wo man ansetzen müsste. für mich bedeutet das, dass man sich von einer schlechten abbildung verabschiedet und richtig stellt. wenn man das nicht macht, werden die probleme auf dauer wieder auftauchen.
nebenbei bemerkt bin ich nicht frustriert. der hinweis kommt von ortwin. und den gebe ich auch gerne wieder dorthin zurück. ich erlaube mir einfach zu sagen, was aus meiner sicht sache ist. in bezug auf die qualität des erd von contenido braucht aus meiner sicht keine diskussion geführt zu werden. der normalisierungsgrad ist eine messbare grösse. wir haben bereiche, die erfüllen nicht einmal die erste normalform. es ist also ausgeschlossen, dass das datenmodell gegen ungewollte und ungültige zustände resistent ist. das resultat sind aktualisierungsanomalien auf der einen und unvollständige aktualisierungen aufgrund des abbruchs des php-scriptes auf der anderen seite. solange diese probleme nicht an die hand genommen werden, werden solche probleme auch weiterhin auftreten. weil diese ursache ist bekannt. es mag noch andere geben. aber wenn bei einer rechnung 9 von 10 fehler eliminiert werden, bleibt das resultat immer noch falsch.
ich weiss mittlerweile, dass es nicht schmeckt, wenn man die probleme beim namen nennt. macht das aber niemand, bleibt es immer gleich. und mit lösungen werde ich nicht mehr aufwarten, da die dann einfach nicht integriert werden.