Ich versuche, ein Gefühl dafür zu bekommen, wie die Benutzer/Rollen-Beziehungen für eine Anwendung implementiert werden, die ich schreibe. Der Persistenz-Layer ist der Datenspeicher von Google App Engine, der einige interessante (aber im Allgemeinen nützliche) Einschränkungen für die möglichen Aktionen enthält. Irgendwelche Gedanken werden geschätzt.Benutzer und Rollen im Kontext
Es könnte hilfreich sein, die Dinge sehr konkret zu halten. Ich möchte, dass es Organisationen, Benutzer, Testinhalte und Testverwaltungen gibt (Aufzeichnungen der durchgeführten Tests). Ein Benutzer kann die Rolle eines Teilnehmers (Testteilnehmers), eines Mitwirkenden von Testmaterial oder beides haben. Ein Benutzer kann auch Mitglied von null oder mehr Organisationen sein. In der Rolle des Teilnehmers kann der Benutzer die vorherigen Verwaltungen von Tests sehen, die er oder sie genommen hat. Der Benutzer kann auch eine Testverwaltung eines anderen Teilnehmers sehen, wenn dieser dem Benutzer die Berechtigung erteilt hat. Der Benutzer kann Testmaterial sehen, das veröffentlicht wurde, und er oder sie kann eingeschränkten Inhalt als Teilnehmer während einer spezifischen Verwaltung eines Tests sehen, für den dieser Benutzer von einer Organisation autorisiert wurde. Als Mitglied einer Organisation kann der Benutzer eingeschränkten Inhalt in der Rolle des Mitwirkenden sehen, und er oder sie ist möglicherweise auch in der Lage, den Inhalt zu bearbeiten. Jede Organisation sollte einen oder mehrere Administratoren haben, die bestimmen können, ob ein Mitglied Inhalte sehen und bearbeiten kann und wer Administratorrechte hat. Es sollte auch einen oder mehrere anwendungsweite Superuser geben, die Probleme beheben und lösen können. Mitglieder von Organisationen können die Verwaltungen von Tests sehen, zu denen die Teilnehmer sie autorisiert haben, und sie können anonyme Daten sehen, wenn keine Genehmigung erteilt wurde. Ein Benutzer kann die Testergebnisse eines anderen Benutzers unter anderen Umständen nicht sehen.
Da im App Engine-Datenspeicher keine Joins vorhanden sind, müssen möglicherweise weniger normalisierte Elemente als üblich für die typische SQL-Datenbank verwendet werden, um sicherzustellen, dass Abfragen, die Berechtigungen prüfen, schnell sind (z Link soll angezeigt werden).
Meine Fragen sind:
- Wie ich mich auf diese bewegen? Soll ich viel Zeit investieren, um das Modell richtig zu machen, oder kann ich mehrmals iterieren und nach und nach zusätzliche Komplexität einbringen?
- Hat jemand einige allgemeine Ideen, wie man in diesem Fall Dinge aufteilen kann?
- Gibt es GAE-Bibliotheken, die Rollen auf eine Weise behandeln, die mit dieser Anordnung kompatibel ist?
Vielen Dank für die hilfreichen Antworten. Zu 1 bevorzuge ich definitiv einen iterativen Ansatz zu den Alternativen. Aber mit Datenbanken ist meine Erfahrung ein bisschen anders gewesen, und ich habe den Eindruck, dass es gut sein könnte, mehr Nachdenken zu führen.Und ich habe festgestellt, dass der GAE-Datenspeicher noch schwieriger zu refaktorisieren ist als eine SQL-Datenbank. Ich hoffte also, ein Gefühl dafür zu bekommen, ob irgendjemand da draußen, der etwas Ähnliches getan hat, wissen könnte, welches Gleichgewicht zu schlagen ist. Re 3, Ich benutze app-Engine-Patch, aber ich denke nicht, Django hat ein Konzept von Zwischenorganisationen (oder Konten). –
Sie haben Recht, GAE (und Datenbanken im Allgemeinen) machen das Refactoring schwierig. Normalerweise ist der Pfad, den Sie auswählen, nur Datenrefaktor, die Spalten hinzufügen, niemals entfernen. Dies mag ein wenig einfacher sein, da GAE jetzt Daten hochladen kann, aber diese Art von Problem war einer der Gründe, warum ich GAE für bezahlten Serverraum verlassen habe. –