n:n Beziehungen und SQL-Select Anweisungen

Ich habe in den letzten Tagen den Joomla! Kurs auf Galileo durchgearbeitet. Dieser basiert ja noch auf Version 1.5. Mir fiel dabei vorallem die streng hirarchische Baumstruktur Bereich-Kategorie-Beitrag auf. Leider verstehe ich nicht ganz, weshalb man die gewählt hat, da doch Joomla! mit einem RDBS arbeitet. Auch die Menüs lassen offenbar nur Aufrufe innerhalb dieser Baumstruktur zu.

Wie ist das bei Version 1.6?

1. Kann ich Beiträge mehreren Kategorien und mehreren Bereichen zuordnen, also quasi eine n:n Beziehung herstellen?

2. Kann ich eine eigene Datenbankstruktur anlegen, resp. die bestehende um neue Tabellen und Relationen erweitern?

3. Kann ich einem Menüpunkt eine SQL-Select Anweisung hinterlegen und damit in der Datenbank die gewünschten Elemente (z.B. Bereiche, Kategorien, Beiträge) zusammenstellen und formatiert anzeigen?

Offenbar werden meine Frage nicht verstanden. Deshalb hier noch eine Ergänzung. So müsste die Datenbank-Struktur grundsätzlich aussehen, wenn man Elemente unäbhängig von einer Struktur zuordnen will.

[attachment=0:2ldor70i]<!-- ia0 dbstruktur.jpg<!-- ia0 [/attachment:2ldor70i]

In der Tabelle Elemente liegen sowohl die Beiträge wie auch die Kategorien. Im Feld Typ werden sie unterschieden. Jeder Typ besitzt dann eine Attribut-Tabelle (Attr. Beitrag, Attr. Kategorie), in welcher die Typ-spezifischen Felder sind.

In der Tabelle Zuordnung werden jeweils zwei Elemente verknüpft. Also zum Beispiel ein Beitrag einer Kategorie zugewiesen. Natürlich können dort für jedes Element beliebig viele Einträge stehen, oder auch keiner!

Will ich nun auf einer Webseite zum Beispiel die News anzeigen, so selektiere ich zuerst in Elemente nach dem Namen News und dem Typ Kategorie. Mit der entsprechenden IDE, hier also 3, selektiere ich in Zuordnung und lese die entsprechende IDE 1 heraus. Als erste finde ich 1. Damit selektiere ich in Attr. Beitrag und hole mir die Daten des ersten Beitrages, welcher mit den News verknüpft ist. Sollen nur die Beiträge des aktuellen Monates angezeigt werden, dann schränke ich die Selektion entsprechend ein. Dann wiederhole ich das mit den weiteren Beiträgen, also IDE2 und IDE4, welche ich wiederum mittels IDE3 in Zuordnung finde. Will man einen Beitrag (z.B. IDE4) nicht mehr in den News anzeigen, dann löscht man seine Zuordnung (IDZ4) zu IDE3 und schon erscheint er bei der nächsten Abfrage nicht mehr.

Ok, diese Abfrage ist vielleicht etwas aufwändiger, als bloss auf eine vorgegebene Liste zurück zu greifen. Dafür ist sie aber völlig unabhängig von einer Hirarchie. Benötigt man weitere Element-Typen, dann erzeugt man einfach eine neue Typ-Bezeichnung und eine entsprechende Attr.-Tabelle. Auch weitere Zuordnungs-Tabellen können angehängt werden, falls dies nötig sein sollte.

Übrigens, den Elementen könnte man auch Objekte sagen.

Hi Patrick

Offenbar werden meine Frage nicht verstanden.

Doch, das denke ich schon. Doch die Frage ist, was erwartest du da für Antworten?

Wenn du die 1.6 mal installierst und gründlich ausprobierst, dann findest du die selbst:

1. Kann ich Beiträge mehreren Kategorien und mehreren Bereichen zuordnen, also quasi eine n:n Beziehung herstellen?

Nein, in der 1.6 zur Zeit noch nicht. Jedenfalls nicht ohne am Code was zu ändern oder ein sog. 'Content-Construction-Kit' (CCK) zu installieren. Damit würde es ev. gehen. Weiss aber nicht, ob da schon eines auf 1.6 läuft. Die Content-Tabelle hat überigens eine Spalte mit Namen 'xreference' (A reference to enable linkages to external data sets), wird zur Zeit aber (noch) nicht (vom Core) genutzt. Und das Formularfeld 'External Reference' (Beitrag erstellen->rechts unten, Slider 'Metadata') wird dazu genutzt, einen xreference-Header zu erzeugen ( <meta name="xreference" content="xxxxxx" /> ).

2. Kann ich eine eigene Datenbankstruktur anlegen, resp. die bestehende um neue Tabellen und Relationen erweitern?

Eine eigene Datenbankstruktur geht nicht. Jedenfalls nicht ohne dazugehörende Erweiterung(en) die die neue DB-Struktur anspricht. Aber die bestehende erweitern geht schon. Ohne Ende sogar. Die Frage die sich daraus aber ergibt: Wie kommen die nötigen Daten, sprich Zuweisungen in die Tabellen rein? Und wie werden sie wieder ausgelesen? Auch da wieder: entweder selber was schreiben/erweitern (z.B. Content-Plugins), oder CCK benutzen.

3. Kann ich einem Menüpunkt eine SQL-Select Anweisung hinterlegen und damit in der Datenbank die gewünschten Elemente (z.B. Bereiche, Kategorien, Beiträge) zusammenstellen und formatiert anzeigen?

Nein. Jedenfalls nicht 'von Haus aus'. Aber wenn du ein CCK findest, das multiple Kategorie-Zuweisungen zulässt, dann erübrigt sich ja dieser Punkt von selbst. Oder du fügst der 'com_content' eine neue, zusätzliche View hinzu, die als Menuparameter ein SQL-Statement o.ä. entgegennimmt und umsetzt.

Das längst nötige und auch überfällige dynamische Rechtesystem ist nun in Joomla drinn. Ein weiterer Punkt ist der Content selbst, der einiges an möglichen Features vermissen lässt. Aber dieser Punk wird anscheinend mit der nächsten Version angegangen:
--ALTER LINK WURDE ENTFERNT--

Cheers
Roger

Hallo Roger

Ok, ich sehe, dass man bezüglich der DB-Struktur so einige Überlegungen anstellt. Inzwischen probiere ich auch an Typo3 rum und kann dort die Auswirkungen eines objektorientierten Ansatzes deutlich erkennen, vorallem in der Bedienung des backend. Sicher kennst Du das Projekt auch etwas. Die Idee mit der Version 5, welche quasi paralell zu der 4.x aufgebaut wird und dann zu einem "grossen Systemwechsel" führt, finde ich nicht so schlecht .

PS: Etwas mit meinem login hier stimmt nicht. Der erste wird nie zugelassen. Es steht ich hätte meine maximale Anzahl Versuche überschritten ( und das beim ersten Versuch?!). Dann muss ich diesen Bestätigungscode eingeben mit den Buchstaben und Zeichen. Das klappt dann. Woran liegst?

Bezugnehmend auf Tribals/Rogers Antwort: FLEXIcontent ist in einer Version (glaube noch Beta) für Joomla 1.6 verfügbar und kann soweit ich gesehen hab mehr oder weniger die Dinge die Roger mit "... ein CCK einsetzen..." angibt.

Nun, es ist schon ein Weilchen her seit meinem Informatikstudium (1989-92, HTL Brugg Windisch). Da träumten wir noch nicht einmal von solchen Tools wie Joomla! Dafür war das wenige, was wir hatten, gut dokumentiert und es gab auch nicht alle paar Monate (oder Wochen) eine neue Version. Hat Vor- und Nachteile .

Ok, später ging ich eher ins Projektmanagement. Trotzdem hatte ich mal mit Oracle und so einem Report-Builder zu tun. Da konnte man relativ grafisch unterstützt auf die Tabellen zugreifen (nur select) und sich so eine recht komplexe Abfrage zusammen stellen. Diese musste man dann noch formatieren, damit sie als Liste ausgegeben werden konnte. War das ganze so, wie man es haben wollte, konnte man die Abfrage speichern und sogar exportieren. Dann legte man (in Windows 3.11 : ) ) ein Icon an und wies diesem die Abfrage zu.

Mit diesem Tool waren wir in der Lage, auch ohne die Hilfe der Software-Entwicklungs-Firma eigene Reports zu generieren und den Endanwendern zur Verfügung zu stellen. Genau so ein Tool müsste man in Joomla als Erweiterung anbieten G_O_O_D O_O_D .

Aber vielleicht ist das ja so ein CCK? Jedenfalls wäre damit Joomla plötzlich nicht nur ein Tool, um hirarchisch aufgebaute Websites zu erstellen, sondern würde sich auch eigenen um solche Dinge zu entwickeln:

--ALTER LINK WURDE ENTFERNT--

Klickt doch mal da rechts ein bisschen herum...toll nicht?!

So ein 'Tool' allgemein, quasi 'stand alone' macht eigentlich wenig Sinn, wenn keine relevanten Daten zum Anzeigen da sind. Die sind in Joomla ja eigentlich erst mit einer entspr. Erweiterung vorhanden (Rezeptesammlung, CD- Büchersammlung, Bilder-Gallerien u.s.w). Ohne diese Eingaben gibts in der Joomla-DB ausser Content eigentlich nichts mehr, was sich da anzeigen lohnen würde.

Und diese Erweiterungen haben auch meist oder zumindest manchmal solche dazugehörenden Module, die sowas ähnliches anzeigen wie dein Beispiel. Die sind überigens auch zusätzlich und/oder nachträglich zu so einer Erweiterung relativ einfach und schnell erstellt: eine DB-Abfrage mit einem Suchkriterium als Modulparameter und dann noch die Anzeige der Resultate als Links..... recht simpel also. Aber wie gesagt, macht ohne eine dazugehörende Erweiterung nicht wirklich Sinn.

Hallo Tribal6

Klar, ohne entsprechende Daten, welche flexibel angezeigt werden müssen, braucht es auch keine flexible Anzeige. Ich wollte bloss aufzeigen, dass nicht alle Inhalte immer hirarchisch aufgebaut sind. Viele Informationen haben unterschiedliche Themen und sollten deshalb auch unter diesen Themen gefunden werden können. Es gibt ja bereits Erweiterungen, welche in die Richtung gehen, z.B. ein Dokumentenmanagement oder ein Online-Shop.

Ich bin vielleicht manchmal etwas zaghaft, wenn ich was rüber bringen will. Es geht um die Datenbank-Struktur. Die Normalform ist nicht ok. In meinem Beispiel weiter oben habe ich die 2. Normalform benutzt. Besser wäre die 3. Normalform. Dazu müsste man mit dem Feld Typ in der Tabelle Elemente noch etwas tun, nämlich die Typen selbst als Elemente führen und eine Tabelle Attr. Typ anhängen. Dort drin würden dann die Funktionen verwaltet, die auf einem Typ zugelassen sind, z.B. create, edit, delete etc.

Wenn eine DB-Struktur nicht in der 3. Normalform ist, dann gibt das früher oder später Probleme. Deshalb sollte Joomla so schnell als möglich die DB-Struktur normalisieren und zwar konsequent. Doch dies ist sehr schwierig, wenn bereits viel Funktionalität besteht und auch noch ein Heer von Erweiterungen. Diese müssen nämlich alle überarbeitet werden.

Deshalb mein Hinweis auf das Vorgehen von Typo3 bezüglich Version 5. Joomla sollte ein zweites Team bilden mit starken Datenbankleuten. Diese sollten auf eine zukünftige Version 2 hinarbeiten:

1. Datenbank normalisieren auf 3. Normalform
2. Kernfunktionalität auf 3. Normalform anpassen
3. Unterstützung der Umbauten bei den Erweiterungen

So ein Unterfangen ist nicht klein, doch ohne wird Joomla wohl immer mehr Probleme erhalten. Typo3 kommt ca. 2012 mit Version 5 heraus (vielleicht auch erst 2013 ). Da Joomla noch viel kleiner ist als Typo3, könnte die Zeit also ausreichen, um mit Typo3 gleichzuziehen. Ein Framework kann man ja auch dann noch anpacken.

--ALTER LINK WURDE ENTFERNT--

Ihr solltet das unbedingt in Angriff nehmen. Besser früher als später!