nicht angemeldet
Hi!
Was ist denn an diesem Diagramm PHP - was ist daran überhaupt Code?
Nichts, ich wusste nur nicht wie ich es besser darstellen kann aufgrund der "verschluckten" Leerzeichen nei normaler Darstellung im HTML.
Wie hätte ich es machen sollen?
Einfach einstellen. Die Forumssoftware darf Code auch dann nicht verhauen, wenn er nicht als solcher ausgezeichnet ist, und sie macht das auch nicht. Siehe mein zweites Verknüpfungsbeispiel. <code> ist auch normales HTML, und normalem HTML kann man mit CSS beibringen, Whitespace-Zeichen nicht zusammenzufassen.
Welche Daten willst du hauptsächlich haben und was ist das Zubehör? Beispieldaten und die des gewünschten Ergebnisses wären hilfreich.
Was meinst du mit Zubehör? Beispieldaten wären einfach verschiedene ids.
Haben will ich "am Ende" ein Array/Objekt, dass mir Informationen über den Seiteninhalt entsprechend dem User gibt. Davon abhängig ist in welchen Gruppen er ist, welche Module und welche Seiten für diese Gruppe existieren.
Nach deinem Ergebnis-Objekt zu schließen sind die Seiten die eigentliche Begierde und die Modul- und Gruppendaten das "Zubehör" - oder Pages sind die Master-Daten, Modules und Groups die Details. (Die Einschränkung nach einem bestimmten User mal unbeachtet gelassen.)
Am Ende hätte ich gern ein Page-Objekt:
object
{
// table.pages
page array('pageID' => $pageID, // Alias für table.pages.id
'pageData1' => $pageData1, // Alias für Spalten
'pageData2' => $pageData2,
/../)// table.modules
modules array(moduleID1 => array('modulData1_1' => $modulData1_1, // moduleID1 = Alias für table.modules.id
'modulData1_2' => $modulData1_2), // modulData1_1, 1_2,.. = Alias für Spalten
moduleID2 => array('modulData2_1' => $modulData2_1,
/../)),// table.groups
groups array(groupsID1 => array('groupData1_1' => $groupData1_1, // groupsID1 = Alias für table.groups.id
'groupData1_2' => $groupData1_2, // groupData1_1, 1_2,.. = Alias für Spalten
'groupData1_3' => $groupData1_3, // aus table.groups
/../),
groupsID2 => array(groupData2_1 => groupData2_1,
/../))
}
Und das ist mit einer Abfrage zwar nicht unmöglich aber äußerst unhandlich zu bewerkstelligen. Das Ergebnis einer Abfrage ist eine flache Struktur: x Spalten und y Reihen. Du willst aber am Ende eine Baumstruktur haben, in der unterschiedliche Daten in den Zweigen stehen. Somit würde ich mehrere Abfragen vorschlagen. Die erste fragt die Seiten. Auch das wird schon ein Join-Monster, weil du, um nach den Nutzern einschränken zu können, über die Gruppen zu den Nutzern joinen muss - und das über die m:n-Verknüpfungstabellen. Als Ergebnis erhältst du die Page-Daten. Die nächste Abfrage ermittelt alle Gruppen-Daten zu den in den Page-Daten enthaltenen Page-IDs. (Page-IDs separieren und eien IN (...) Bedingung erstellen. Zu joinen brauchst du nur die m:n-Tabelle rel\_groups\_pages und das IN prüft auf deren pageID.) Das gleiche noch mit den Modulen.
Nicht betrachtet habe ich die Beziehung zwischen Modulen und Gruppen, weil mir deren Aufgabe noch nicht ganz klar ist. Warum gibt es eine Beziehung zwischen Seiten und Gruppen und noch eine zwischen Modulen und Seiten? Sind manche Seiten Modulen zugeordnet und ist der User über die Modul-Gruppen-Beziehungen und seiner Gruppenzugehörigkeit zu Handlungen an diesen Seiten berechtigt, auch wenn keine Zugehörigkeit zwischen Seite und Gruppe existiert? Und gibt es dann andererseits Seiten ohne Modulzugehörigkeit, die über einzelne Gruppen-Seiten-Verknüpfung dem User zugänglich sind? (Was ist, wenn Nutzer unabhängig von Gruppenzugehörigkeiten für Seiten berechtigt werden sollen? Dann hättest du noch einen weiteren Beziehungsweg.) Insgesamt scheint mir, dass du hier die Strukturen vereinfachen solltest, um diese zirkulären Beziehungen wegzubekommen. Vielleicht sollten Einzelseiten auch (Dummy-)Modulen zugeordnet werden müssen. Dann sind die Abfragen durch die m:n-Tabellen zwar immer noch nicht wirklich einfacher, aber der Weg ist eindeutig.
Lo!