Ist es besser, eine SQL-Tabelle zu strukturieren, um eine Übereinstimmung zu haben, oder kein Ergebnis zurückgeben

Question

Ich habe eine interessante Design-Frage. Ich entwerfe die Sicherheitsseite unseres Projekts, um verschiedene Versionen des Programms für unterschiedliche Kosten zu ermöglichen und um auch Managern zu erlauben, anderen Benutzern den Zugriff auf Teile des Programms zu gewähren oder zu verweigern. Es wird webbasiert und auf unseren Servern gehostet.

Ich verwende eine einfache Zulassen oder Verweigern Option für jede 'Ressource' oder Bildschirm.

Wir werden eine große Anzahl von Ressourcen haben, und der Benutzer wird in der Lage sein, viele verschiedene Gruppen einzurichten, um Benutzer zur Kontrolle des Zugriffs zu bewegen. Jeder Benutzer kann nur zu einer einzigen Gruppe gehören.

Ich habe zwei Ansätze in diesem Sinne, und war neugierig, was für den SQL-Server in Bezug auf die Leistung besser wäre.

Option A Das Vorhandensein eines Eintrags in der Zugriffstabelle bedeutet, dass der Zugriff zulässig ist. Dies benötigt keine Spalte in der Datenbank, um Informationen zu speichern. Wenn keine Ergebnisse zurückgegeben werden, wird der Zugriff verweigert.

Ich denke, dies wird eine kleinere Tabelle bedeuten, aber würde Abfragen die gesamte Tabelle durchsuchen, um festzustellen, gibt es keine Übereinstimmung?

Option B Eine Bitspalte ist in der Datenbank enthalten, die Zulassen/Verweigern steuert. Dies bedeutet, dass immer ein Ergebnis gefunden wird und eine größere Tabelle erstellt wird.

Gedanken?

Answer 1

Wenn es nur Zulassen/Verweigern ist, dann würde eine einfache Verknüpfungstabelle zwischen Benutzern und Ressourcen funktionieren. Wenn in der Verknüpfungstabelle ein Eintrag für die Benutzerressource angegeben ist, erlauben Sie den Zugriff.

UserResources 
------------- 
UserId FK->Users 
ResourceId FK->Resources 

und die sql so etwas wie

if exists (select 1 from UserResources 
where UserId = @uid and ResourceId=@rid) 
set @allow=1; 

mit einem Clustered-Index auf (Benutzer-ID und ResourceId) wäre, die Abfrage blendend schnell sogar mit Millionen von Datensätzen wäre.

Answer 2

Ich würde für Option B stimmen. Wenn Sie mit Option A gehen und davon ausgehen, dass wenn ein Benutzer existiert, können Sie hineingehen, dann werden Sie schließlich auf das Problem stoßen, dass Sie den Zugriff verweigern möchten Benutzer, ohne den Benutzerdatensatz zu entfernen.

Es wird viele Fälle geben, in denen Sie einen Benutzer sperren, aber nicht vollständig sein Konto zerstören wollen. Eine solche Instanz (nicht unbedingt mit Ihrem Anwendungsfall verbunden) ist, wenn Sie nicht zahlen, und sie Ihr Konto abschneiden, bis Sie wieder zahlen. Sie möchten den Datensatz nicht löschen, da sie ihn immer noch aktivieren möchten, wenn Sie erneut zahlen, anstatt das Konto von Grund auf neu zu erstellen und den gesamten Benutzerverlauf zu verlieren.

Answer 3

B. Es ermöglicht viel besser überprüft, ob die Daten vollständig sind (zum Beispiel, wenn Sie eine zulässige/deniable-Funktion hinzufügen).

Tabellengröße sollte auch nur für Tabellen in Betracht gezogen werden, von denen Sie wissen, dass sie viele Datensätze enthalten (wie in 100.000+). Sie nehmen sogar die Zeit, um die Größe der Tabelle Größe in diese Frage bereits kosten mehr als die zusätzlichen Festplattenplatz, den es dauern würde.

Answer 4

Ansatz A, aber ich würde auch eine explizite verweigern zusätzlich zu Ihnen impliziten deney. Ich würde einige Anwendungsfälle machen, um sicher zu gehen, dass Ihre Endlogik funktioniert, aber hier sind einige Beispiele.

User1 is in group1 and group2. 
User2 is in group1 
User3 is in group2 

---

Folder1 allows group1 and deny group2. 
User1 is denied. 
User2 is allowed. 
User3 is denied. 

Ich glaube, Ihr Ansatz Nutzer1 erlaubt wäre.