nicht angemeldet
Hallo Vinzenz.
Wenn es sich um eigenständige Module handelt, die z.B. installiert und freigeschaltet werden können, dann ist das durchaus ok. So habe ich Dich aber nicht verstanden.
Genau so war es allerdings gemeint. Ok, da wir nun offensichtlich von der gleichen Sache reden, kommen wir zum Thema. :-)
Was hat dies mit Deiner Ausgangsfragestellung zu tun? Ich zitiere:
allerdings stört mich etwas daran. An der Stelle, wo die zu einem Knoten gehörige Seite gefunden werden soll, muß ich quasi mit allen vorhandenen Typen von Seitentabellen vergleichen, ob ein Eintrag mit bestimmter Knoten-ID existiert.
Das verstehe ich in dem von Dir skizzierten Zusammenhang überhaupt nicht. Der Knoten muss selbstverständlich *wissen*, wo seine Daten zu finden sind - und diese nicht ziellos suchen.
Genau dort setzte meine Frage an. Wenn das Programm wirklich _nur_ eine Knoten-ID erhält, weiß es nicht, wo die zugehörige Seite zu suchen ist. Eine Möglichkeit wäre wie gesagt das "Durchsuchen" aller Tabellen, die Seitentypen repräsentieren. Da die Knoten-ID nur einmalig vergeben wird, wird sie entweder genau in einer dieser Tabellen gefunden oder gar nicht. Das ist nicht wirklich "ziellos", aber eben sehr aufwendig.
Das wird also ein ziemlich großer JOIN, in dem alle möglichen Tabellen vorkommen -- eben so viele, wie unterschiedliche Seitentypen existieren.
Nein, natürlich nicht. Der Typ ist im Knoten vermerkt.
Das war eine der Umstrukturierungsvorschläge, um die ich eingangs bat. Danke. :-) Du schlägst also vor, den Seitentyp mit im Hierarchiebaum zu speichern. An irgendeiner zentralen Stelle im Programm -- dort sind bei Ergänzungen neuer Seitentypen dann auch Ergänzungen nötig -- muß also vermerkt sein, welcher Typeneintrag in diesem Baum welcher Tabelle entspricht. Hmm, ok. Ist 'ne Möglichkeit. Ich wollte im Hierarchiebaum eigentlich wirklich nur ganz abstrakt "Seiten" abbilden, unabhängig vom speziellen Typ. Aber mit dieser Zusatzinfo ist es einfacher zu handhaben. So werd ich's wohl machen.
Ich könnte die benötigte Query dynamisch aus allen "bekannten" Tabellennamen zusammensetzen, dann muß ich bei Ergänzungen neuer Seitentypen zumindest nicht die jedesmal von Hand die Query umschreiben. Trotzdem wächst bei solchen Ergänzungen dieses JOIN-Gebilde immer und immer weiter.
Das ist eben ein falsches Konzept. Bestehendes darf nicht durch ein Erweiterungsmodul verkompliziert werden.
Meine Rede. Genau deshalb überhaupt dieser Thread, um den bisherigen Ansatz zu diskutieren. ;-)
Grüße von Alex
Auge