Kategorienreihenfolge mit PostID und PreID

[kummer]

Ich habe folgendes Problem festgestellt:

Die Reihenfolge von Kategorien wird ja über die PostID und die PreID festgelegt. Das funktioniert auch einwandfrei, solange man nicht mehrere Sprachen angelegt hat. Werden allerdings andere Sprachen angelegt und nicht alle Kategorien synchronisiert, dann kann es vorkommen, dass die PostID einer Kategorie auf eine Kategorie zeigt, welche in der aktuellen Sprache nicht vorkommt. Das muss fast notwendigerweise zu Problemen mit der Navigation führen.

Wäre es für die Festlegung der Reihenfolge nicht besser, einen Zähler zu integrieren? Das Vorgehen wäre dann so, dass - wenn eine Kategorie z.B. zwischen die Kategorie 7 und 8 zu placieren wäre, dann würde einfach mit einer Aktualisierungsabfrage alle Sortierkriterien aller Kategorien, welche grösser oder gleich 8 sind um eins erhöht und die neue Kategorie würde die 8 erhalten. Dann könnte man auch die Reihenfolge direkt durch ein Order By in der Abfrage regulieren.

Oder gibt es ein gute Lösung, das Problem mit der PostID bei Mehrsprachigkeit und nicht vollständiger Synchronisation zu lösen?

MfG,
Andreas

[emergence]

ähm nun ja
bei mehrsprachigkeit hab ich da noch kein problem feststellen können...
da jede kategorie nur einmal in jeder sprache vorkommen darf...
PostID und PreID haben ja mit der reihung der kategorien zu tun...
die reihung mit einem zähler vorzunehmen ist komlizierter wie es den anschein hat.... (ob die queries dann wirklich einfacher werden ?)
da ergibt sich dann das problem wenn ich eine neue kategorie in der ersten erstelle wie soll das dann mit dem zähler klappen ? da müssten jede menge`werte nachmodifiziert werden...

das läuft auf eine komplette entkoppelung hinaus und das ist glaube ich auch nicht zielführend...

was möchtest du denn genau erreichen ?

[timo]

das ist eigentlich ein recht guter punkt...ob das jetzt zu probleme führt weiß ich nicht, aber bisher habe ich nichts dergleichen feststellen können, denn:

- Jede Kategorie ist grundsätzlich in jeder Sprache vorhanden.
- Ob der Sprachabhängige Teil dann vorhanden ist, ist eine andere Frage...

[kummer]

nein, eine kategorie ist in einer sprache erst vorhanden, wenn die kategorie synchronisiert worden ist. wenn nicht alle kategorien synchronisiert werden, dann entsteht eine lücke (die PostID zeigt dann auf eine kategorie, die es in der aktuellen sprache nicht gibt).

das wäre ja nicht so schlimm. man könnte ja auch einfach alle kategorien synchronisieren. wenn nun allerdings in einer anderen sprache ein zusätzliche kategorie angelegt und hinauf verschoben wird, dann hat man wieder eine lücke und müsste neu synchronisieren.

aus meiner sicht besteht da schon ein problem, dass der lösung harrt.

[timo]

nein, eine kategorie ist in einer sprache erst vorhanden, wenn die kategorie synchronisiert worden ist. wenn nicht alle kategorien synchronisiert werden, dann entsteht eine lücke (die PostID zeigt dann auf eine kategorie, die es in der aktuellen sprache nicht gibt).

Ähm falsch (oder wir haben aneinander vorbeigeredet )...deshalb sagte ich ja: Die Kategorie als solches ist NUR die idcat. Der sprachabhängige Teil einer Kategorie ist die idcatlang. Hast du z.b. eine Kategorie "Hallo" im deutschen, dann hat diese z.b. die idcat 1, und die idcatlang 15. Syncronisierst du "Hallo" ins Englische, dann hat diese immer noch die idcat 1, aber z.b. idcatlang 27. Da die Tree-Sortierung aber nur über idcat's funktioniert, ist das eigentlich richtig.

Aber im allgemeinen hast du schon recht - die "Lücke" vom Sprachabhängigen Teil ist da; nur die Kategorie selbst (obwohl sie eigentlich nur eine Nummer ist) natürlich nicht.

wenn nun allerdings in einer anderen sprache ein zusätzliche kategorie angelegt und hinauf verschoben wird, dann hat man wieder eine lücke und müsste neu synchronisieren.

Ähm nein....verschiebt man das ganze in einer Sprache, verschiebt es sich auch in der anderen. Nochmal syncronisieren mußt du nicht...

[kummer]

wenn man eine neue kategorie anlegt und diese verschiebt, gibt es sie in der anderen sprache eben noch nicht. deshalb die lücke und deshalb neu synchronisieren.

das problem ist folgendes: natürlich ist eine kategorie nur eine id. und dann gibt es einen sprachabhängigen teil. aber in sql spielt das eben keine rolle, weil ich ein kartesisches produkt bilden muss, um die abfrage vorzunehmen. und dann entsteht eben scheinbar eine tabelle mit allen informationen. wenn ich dann das resultat auf eine sprache einschränke (where idlang = $lang), dann haben wir eine lücke.

langer rede kurzer sinn: die lücke stört, da man nicht zur nächsten kategorie gelangt, wenn diese in der aktuellen sprache nicht synchronisiert ist.

die frage, die sich nun stellt: gibt es einen workaround, der es nicht erfordert, für jede einzelne kategorie wieder eine abfrage vornehmen zu müssen?

man könnte ja folgendes machen: (1) abfrage aller idcat mit parentid = navigationsstart und dann (2) für jede kategorie eine abfrage der entsprechenden sprache vornehmen. aber das ist nicht wirklich elegant. deshalb würde ich vorschlagen, das ganze über ein sortierschlüssel zu lösen. das ist weniger kompliziert als es scheint.

ich würde folgendes vorgehen vorschlagen:

(1) tabelle um einen sortierschlüssel ergänzen

(2) eine neue kategorie erhält als sortierschlüssel max(sortierschlüssel) where parentid = idcat der übergeordneten kategorie.

(3) wird diese kategorie nach oben verschoben, müssen lediglich die sortierschlüssel vertauscht werden (= 2 aktualisierungsabfragen). wenn die neue kategorie z.b. die 12 erhält und nach oben verschoben wird, dann ist die kategorie mit der gleichen parentid und dem sorierschlüssel 11 um eins zu erhöhen und die aktuelle um eins zu erniedrigen. insgesamt keine grosse sache und es löst das problem.