Userverwaltung: Rechtevergabe

[archie]

Hi Leute, da ich aus Langeweile, mal ein neues Projekt scripten will, habe ich mich entschieden eine kleine Flirtcommunity ohne Aussicht auf Erfolg zu coden. Wer weiß, schaden kann es niemanden und es ist besser, als die Freizeit in Onlinegames zu investieren.

Mein Ziel dabei ist, zu lernen, wie man die ganzen Sachen optimiert und gut strukturiert programmiert. Desweiteren will ich mich endlich wagen Klassen zu verwenden. Jetzt überlege ich schon seit 2 Wochen rum und merke mir gute Ideen.
Was ich damit erreichen will:
-> Arbeit mit Klassen, abgeleiteten Klassen
-> Gutes Usermanagement
-> Optimale MySQL nutzung usw.
-> Und letzendlich eine Community, wo kein Geld verlangt wird!

So zu meiner Frage, damit ich nicht riesengroße Usertabellen habe, habe ich mir überlegt mehrere Einstellungen in einer DB Zeile zu speichern, diese dann als arry betrachten und dementsprechend auswerten. Empfielt sich sowas überhaupt?
Beispielzeile: options, der Datesatz dadrin: 0|2|1|0|0|
je nach stelle, werte ich die Sachen aus, z.B. Newsletterempfang stelle 1 -> 0 -> kein Newsletter Empfang aktiviert.
Oder stößt man irgendwann auf Grenzen, die ich jetzt noch nicht weiss?

[ghostgambler]

Re: Userverwaltung: Rechtevergabe

Original geschrieben von archie
Oder stößt man irgendwann auf Grenzen, die ich jetzt noch nicht weiss?

Das eckt an der ersten Normalform von Datenbanknormalisierung an...

Die erste Normalform erlaubt nur atomare Attribute in den Relationenschemata, d.h. als Attributwerte sind Elemente von Standard-Datentypen wie integer oder string erlaubt, aber keine Konstruktoren wie array oder set

Und ich würde es auch aus eben diesem Grund nicht benutzen, weil -> die Normalisierung gibt es nicht zum Spaß. Wenn man später den String (der bei dir ja nur eine vereinfachte Form eines Arrays ist, damit du ihn in der DB speichern kannst) erweitern will/muss, hast du ein Konsistenz Problem, weil die Strings unterschiedlich lang sind. Du musst die eine Klasse/Funktion anlegen die die Einstellungen ausliest und ggf. einen Standard-Wert zurückgibt (der ansonsten direkt als default pro Spalte in MySQL belegt werden würde) und und und...ich hatte sowas einmal und finde es bis heute doof, dass ich das gemacht habe >_>

[archie]

Mmhh, stimmt da hast du Recht, es macht die Sache übersichtlicher, aber wiederrum auch schwerer zu handhaben :/

[goth]

Ich würde einfach nicht auf ghostgambler hören ... das Zitat hat er gerade mal auswendig gelernt und wendet es jetzt hier im Forum immer wieder neu an.

Normalisierung, insbesondere gilt das allerdings für die höheren Normalformen > 3, sind gerade wenn es um Performance bei Web-Anwendungen geht eher kontraproduktiv und somit ein eher theoretisches Konstruct.

Es ist klar, Normalisierung die Informations-Redundanz vermeidet ist gut, schön und wichtig, das von Ihm hier gewünschte Normalisieren eher nicht.

Keine Ahnung ob es bei ghostgambler der "ich hab' was neues gelernt" -oder "ich weiss was" - Effekt ist ... aber auch er wird irgendwann feststellen, das ein JOIN über 5 Tabellen unter Umständen, selbst mit tollster Indizierung verdammt langsam werden kann ... !

An Deiner Stelle würde ich mir allerdings mal den Datentype SET anschauen. Meines Erachtens für eine Verwaltung von Berechtigungen besser geeignet als Dein Ansatz.

[archie]

@ goth: Danke für die Info über SET!
PS: JOIN ist ja eine ganz nützliche Sache, wenn man eine kleine Tabellen abfragt, bei eher größeren Sachen z.B. Foren mit 1 Mio Beiträgen, wird es schon kritisch, da hast du Recht.
PS: was macht eigentlich mein lieber "HAND" der mir damals die Angst genommen hat php zu lernen

[mrhappiness]

Ich hab' es einmal so gemacht, dass ich alle Daten in der 3. Normalform vorhalte, aleerdings wird beim Ändern der Daten im Admin-Bereich auch eine Tabelle generiert, die nicht in 3. NF ist, diese Tabelle wird im Live-Betrieb zur Abfrage genutzt.

Tabelle users mit user_id
Tabelle right_groups mit rg_id
Tabelle right_rights mit rr_id
Tabelle right_groups__user mit rg_id und user_id
Tabelle right_rights__users mit rr_id und user_id (für Zuweisung oder Entzug nur einzelner Rechte)

Tabelle right_live
user_id | rr_id | rg_id | active

Im Live-Betrieb frage ich nur so ab

SELECT active
FROM right_live
WHERE 
  user_id = 5
  AND rr_id = 'CREATE_NEWS'

zur Abfrage einer Berechtigung und

SELECT active
FROM right_live
WHERE 
  user_id = 5
  AND rg_id = 'NEWS'

zur Abfrage einer Berechtigungsgruppe
Die Tabelle right_live sieht zwar aus wie Hölle (mal steht was in rr_id, aber nicht in rg_id, mal steht was in rg_id aber nicht in rr_id, ...)
Wenn jemand alle 3 Rechte einer Gruppe hat, gibt's dafür insgesamt 4 Einträge (3 für die Rechte und 1 für die gesamte Gruppe), aber es ist recht schnell...

[ghostgambler]

Original geschrieben von goth
Ich würde einfach nicht auf ghostgambler hören

wenn ich das schon lese könnte ich mir sofort den Finger in den Rachen stecken...

... das Zitat hat er gerade mal auswendig gelernt und wendet es jetzt hier im Forum immer wieder neu an.

nein, ich hatte das Zitat grade parat und hab es deshalb in beiden Posts die ich im Abstand von 5 Minuten geschrieben habe verwendet...

Es ist klar, Normalisierung die Informations-Redundanz vermeidet ist gut, schön und wichtig, das von Ihm hier gewünschte Normalisieren eher nicht.

Wenn man davon ausgeht, dass man keinerlei Flexibilität in den Rechten braucht ist das ja auch kein Problem. Aber in meinem Projekt sind die Rechte genauso fest wie Wasser in der Hand, da kann ich so ein Array_to_string_Konstrukt in einer Spalte überhaupt nicht gebrauchen...

Keine Ahnung ob es bei ghostgambler der "ich hab' was neues gelernt" -oder "ich weiss was" - Effekt ist

keine Ahnung ob das bei dir der "ich hab nen Stern"-Effekt ist...

... aber auch er wird irgendwann feststellen, das ein JOIN über 5 Tabellen unter Umständen, selbst mit tollster Indizierung verdammt langsam werden kann ... !

hab ich was gegenteiliges behauptet?


Ich habe an meinem Rechte-System 1 1/2 Tage gessesen um es an meine Bedürfnisse und an die maximal-Ressourcen die das Ding fressen sollte bestmöglich angepasst und das Skript läuft bis jetzt mit der Methode gut.
Dazu muss ich sagen, dass es ein extreme-Skript ist, d.h. die Rechteverwaltung ist exakt auf dieses Projekt zugeschnitten und nicht einfach so übertragbar, für kleinere Projekte, wo auch die Rechte nicht so flexibel sich gestalten können müssen, mag z.B. der Ansatz von mrhappiness besser sein.
Es war nur ein Vorschlag, und dass oben genannter Ansatz gegen die erste Normalform verstößt wird ja auch von keinem angezweifelt, oder?

[php_jan]

Hallo ghostgambler!
Ich mische mich da jetzt mal nicht ein ;-)

Ich habe an meinem Rechte-System 1 1/2 Tage gessesen um es an meine Bedürfnisse und an die maximal-Ressourcen die das Ding fressen sollte bestmöglich angepasst und das Skript läuft bis jetzt mit der Methode gut.
Dazu muss ich sagen, dass es ein extreme-Skript ist, d.h. die Rechteverwaltung is

Den Aufbau deines Rechtesystems würde mich natürlich interessieren...

warum: siehe Signatur!

Gruß,
Jan

[ghostgambler]

Original geschrieben von php_jan
Den Aufbau deines Rechtesystems würde mich natürlich interessieren...

CREATE TABLE `permission_con` (
  `group_id` mediumint(9) NOT NULL default '0',
  `right_id` mediumint(9) NOT NULL default '0',
  UNIQUE KEY `group_id` (`group_id`,`right_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE TABLE `permission_group` (
  `group_id` mediumint(9) NOT NULL auto_increment,
  `group_active` tinyint(4) NOT NULL default '1',
  `group_name` varchar(50) NOT NULL default '',
  `group_namespace` varchar(50) NOT NULL default '',
  `group_desc` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`group_id`),
  KEY `group_namespace` (`group_namespace`),
  KEY `group_active` (`group_active`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 PACK_KEYS=0;

CREATE TABLE `permission_right` (
  `right_id` mediumint(9) NOT NULL auto_increment,
  `right_active` tinyint(4) NOT NULL default '1',
  `right_name` varchar(50) NOT NULL default '',
  `right_desc` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`right_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE TABLE `user_group` (
  `user_id` int(11) NOT NULL default '0',
  `group_id` mediumint(11) NOT NULL default '0',
  UNIQUE KEY `user_id` (`user_id`,`group_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

CREATE TABLE `user_right` (
  `user_id` int(11) NOT NULL default '0',
  `right_id` mediumint(9) NOT NULL default '0',
  UNIQUE KEY `user_id` (`user_id`,`right_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

con ist der Klebstoff zwischen Gruppen und Rechten, right sind die Rechte, group die Gruppen, in den user_*-Tabellen werden die Userzugehörigkeiten zu den globalen Rechten und den Gruppen (zugehörig zu einem namespace) gespeichert.

Den php-Code poste ich nicht, denn der ist sowieso viel zu spezifisch und außerdem poste ich keine 1 1/2 Tage-Arbeit in einem Forum

Generell müsste das DB-Grundgerüst von mrhappiness stammen? Auf jeden Fall stammt die Grundidee hier aus dem Forum, die ich dann, mit meinen Bedürfnissen im Hinterkopf, neu durchdacht habe.

Ich hoffe die Version oben funktioniert...ich hab die Tabellen etwas gekürzt


nyo, mit dem Wegfall der richtigen namespaces (nicht so wie sie hier gewünscht wurde, d.h. ein Bereich Newsletter, ein Bereich Forum, usw.) ist an dem System eigentlich nichts besonderes mehr dran *gähn*



btw. was meinst du denn mit Vererbung in deiner Signatur? *sich da grade nichts drunter vorstellen kann*

[php_jan]

Vielen Dank!
die Struktur kommt mir auch etwas bekannt vor! ;-) ist in diesem Forum auch schon zwei naja ... jetzt 3 Mal vorhanden.

Ich versuche gerade das Rechtemanagement mit Nested Sets ...

http://www.php-resource.de/forum/sho...threadid=63080

Gruß,
Jan

[ghostgambler]

Original geschrieben von php_jan
http://www.php-resource.de/forum/sho...threadid=63080

zu langsam, da war ich schon