• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

[ERLEDIGT] System-Abhängikeit in Tabelle mit Datenbank-Abhängigkeit

CGollhardt

Mitglied
Hallo Miteinander,

mir ist leider kein Aussagekräftiger Titel eingefallen. :???:

Es geht um folgende beiden Tabellen:

Benutzergruppen
Groups.JPG

Rechte jeder einzelnen Benutzergruppe
GroupRights.JPG

Das Problem
- Die Benutzergruppen mit der ID 1-99 sind vom System vorgesehen.
- Alle Benutzergruppen ab der ID 100 können in die Datenbank vom Benutzer eingetragen werden

Zu jeder Benutzergruppe (unabhäng vom Typ) gibt es eine Rechte Tabelle, in der die einzelnen Rechte vorhanden sein sollen. Auch die Rechte von den "Sytem-Benutzergruppen" sollen verändert werden können.

Ich würde gerne nur eine Tabelle mit Benutzergruppen haben. Benutzer können in n Gruppen sein. Hier sollte keine Differenz auf "System oder Datenbank" gemacht werden.

Ich bekomme jedoch Bauchweh dabei, bei der Rechte-Tabelle eine Abhängigkeit zu einer Benutzergruppe zu erstellen die in der Datenbank nicht vorhanden ist. Deswegen habe ich mir gedacht dass ich dort "Dummys reinschreibe", siehe Screenshot.

Die Frage

Kann man das irgendwie besser Lösen? Das fühlt sich für mich wie eine Bastellösung an. Das hat für mich Architektonisch gesehen, einen faden Beigeschmack.

Vielen Dank.
 
Zuletzt bearbeitet:
Werbung:
Wieso sollten die Rechte der Systemgruppen nicht tatsächlich vorhanden sein? Was heißt eigentlich "System"? Ist das eine fertige Software die Du nur ergänzen/nutzen willst? Da sich die System-Benutzergruppen nicht ändern (es gibt ja genau 99) kannst Du natürlich auch Dummies eintragen für jede Gruppe.
 
Hallo,

danke für deine Antwort. Nein es handelt sich um ein selbst geschriebenes CMS System. Also im Prinzip wenn man dies anders machen müsste wäre das kein Problem.

Im Prinzip habe ich eine UserGroup Klasse, die unter anderem eine Get Methode hat (PHP):

PHP:
    static function Get($id)
    {
        $cache = Cache::GetObject('DataSource/UserGroup/' . $id);
        if ($cache !== false) {
            return $cache;
        }
        if ($id <= 99) {
            $group = new UserGroup();
            $group->Id = $id;
            $group->IsSystemGroup = true;
            $group->Rights = Rights::Get($group->Id);
            switch ($id) {
                case 1:
                    $group->Name = Localisation::GetTranslation('View/UserGroups/EveryBodySystemGroup');
                    break;
                case 2:
                    $group->Name = Localisation::GetTranslation('View/UserGroups/RegistredUserSystemGroup');
                    break;
                case 3:
                    $group->Name = Localisation::GetTranslation('View/UserGroups/AdministratorSystemGroup');
                    break;
                default:
                    $group->Name = 'Unbekannte Systemgruppe!';
                    break;
            }
            return $group;
        }
        global $_DB;
        $obj = $_DB->GetObject(self::GetSqlSelect('WHERE id = ' . $id));
        return self::GetBySqlObject($obj);
    }


    static function GetBySqlObject($result)
    {
        $group = new UserGroup();
        $group->Id = $result->id;
        $group->Name = $result->groupname;
        $group->Rights = Rights::Get($group->Id);
        Cache::SetObject('DataSource/UserGroup/' . $result->id, $group);
        return $group;
    }

Ich habe mal gelesen, dass ein Fremdschlüssel Attribut immer als Primär Schlüssel in einer Tabelle sein muss. Bei den Systemverwalteten, ist ja jedoch kein echte Datenbank Eintrag vorhanden.

Ist an dieser Stelle ein Dummy Eintrag am Sinnvollsten?
Oder gar kein Eintrag?
Oder habe ich in meiner Logik (Konzeptionell gesehen) einen Fehler?
 
Werbung:
Ich würde sagen, dass kann man durchaus so machen, auch mit dummy-Datensätzen. In Datenbanktabellen sollte man immer einen Primärschlüssel haben, ein Fremdschlüssel ist nicht zwingend notwendig (nicht jede Tabelle kann ja woanders hin referenzieren). Bei großen Tabellen die oft genutzt werden und viele Spalten haben, sollte man auch noch einen Index setzen, aber das wäre in deinem Fall imho noch nicht notwendig.
 
Zurück
Oben