databaseberechtigungsstruktur

Viele meiner Arbeitgeberanwendungen teilen sich eine ähnliche interne Berechtigungsstruktur, um data auf einen bestimmten Satz von Benutzern oder Gruppen zu beschränken. Gruppen können auch verschachtelt werden.

Das Problem, mit dem wir derzeit konfrontiert sind, ist, dass die Aufzählung der permissions unglaublich langsam ist. Die aktuelle Methode verwendet eine gespeicherte Prozedur mit vielen Cursors und temporären Tabellen. Das hat für kleinere Anwendungen gut funktioniert, aber wir haben jetzt ein bestimmtes System, das schnell wächst und es beginnt zu verlangsamen.

Die grundlegende Tabellenstruktur ist wie folgt;

tblUser {UserID, Benutzername, WindowsLogonName}

tblGroup {GroupID, Name, Beschreibung, SystemFlag}

tblGroupGroup {GroupGroupID, Name,}

tblGroupUser {GroupUserID, Name,}

und alles zusammen zu binden;

tblPermission {PermissionID, SecurityObjectID, SecuredID, TableName, AllowFlag}

die Zeilen wie ..

'5255-5152-1234-5678', '{ID einer Gruppe}', '{ID für etwas in tblJob}', 'tblJob', 1

'4240-7678-5435-8774', '{ID eines Benutzers}', '{ID für etwas in tblJob}', 'tblJob', 1

'5434-2424-5244-5678', '{ID einer Gruppe}', '{ID für etwas in tblTask}', 'tblTask', 0

Sicherlich muss es einen effizienteren Ansatz geben, um alle Gruppen aufzuzählen und die IDs der gesicherten Zeilen zu bekommen?

Um die Dinge weiter zu komplizieren; Wenn ein Benutzer explizit den Zugriff auf eine Zeile verweigert wird, überschreibt dies jegliche Gruppenberechtigungen. Das ist alles in MSSQL.

Ich vermute, dass es sinnvoll wäre, die tblPermission in ein paar Tische auseinander zu brechen: eine für Gruppen und eine für Benutzer. Indem sie beide Gruppen und Benutzer da drüben haben, scheint es dem Design eine Komplexität zu verleihen (und das ist der Grund, warum du die gespeicherten Prozeduren benötigst).

Wenn Sie die tblPermission-Tabelle (in etwas wie tblUserPermission und tblGroupPermission) zerlegen möchten, aber trotzdem eine Darstellung der Tabellen, die wie tblPermission aussieht, können Sie eine view machen, dass die Union die data aus den beiden Tabellen enthält.

Hoffe das hilft. Haben Sie Beispiele dafür, was die gespeicherten Prozeduren machen?

Ich denke, Sie könnten eine rekursive Common Table Expressions ( CTE ) hierarchische Abfrage verwenden. Hier finden Sie viele Beispiele, wenn Sie danach suchen. Das ist einer von ihnen.

Vielleicht ist dein Design in Ordnung, aber die Implementierung / Code ist falsch.

Einige Gedanken:

  • Sind alle Ihre ID Spalten GUID? Nicht empfohlen Kimberley L Tripp Artikel
  • Indizes für alle Fremdschlüssel, vielleicht mit anderen Spalten in Schlüssel oder INCLUDE
  • Routinewartung? zB zersplitterte indizes, stats ot of date etc
  • Sind alle datatypen passend (nimmt keine FKs an): datatypvorrang und implizite Umwandlungserrors können sich einschleichen

Einige weitere Schema-Infos und Beispiele für schlecht durchführenden Code können helfen