Beziehung zwischen ASPNET-Mitgliedschaftsanbietertabellen und benutzerdefinierten Mitgliedschaftstabellen

Question

Ich habe vor einiger Zeit ein Beispiel für benutzerdefinierte Profile durchlaufen und überprüfe ihn jetzt.

Meine Datenbank enthält alle dbo.aspnet_* -Tabellen, wenn ich den ASPNET -Registrierungsassistenten ausführte.In diesen Tabellen habe ich aspnet_Profile, das eine FK-Einschränkung hat, die auf aspnet_Users verweist.

Ich habe auch zwei Tabellen in MyDB:Der erste, DBO.Profiledata, hat eine ausländische Schlüsselbeschränkung, die auf DBO.Profile zeigt.

Ich möchte verstehen, wie sich die Tabellen in MyDB auf die in dbo.aspnet_*beziehen.Sollte es nicht eine fremde Schlüsselbeschränkung (oder eine Beziehung) zwischen den Profiltabellen in MyDB und den ASPNET -Tabellen geben?Einige Diskussionen darüber, wie meine benutzerdefinierten Tabellen auf die von ASPNET bereitgestellten Tischen beziehen, wäre wunderbar.

Dank im Voraus.

Answer 1

Ich sehe zwei Optionen, die beide im Grunde zum gleichen Ergebnis führen:

• FK von dbo.aspnet_User.UserID Zu dbo.Profile.UserID, und definieren Sie dann einen eindeutigen Schlüssel dbo.Profile.UserID (es sei denn, Sie verwenden es als PK-Spalte für dbo.Profile)

• FK von dbo.aspnet_Profile.ProfileID Zu dbo.Profile.ProfileID

dbo.aspnet_User ist logischerweise 1 - 1 mit dbo.aspnet_Profile, Es spielt also keine Rolle, welchen Ansatz Sie verwenden, da Sie immer noch die gleiche relationale Integrität erhalten.

Wenn Sie die Standard-Profildatentabelle durch Ihre eigene Implementierung ersetzen, ist es sinnvoller, den ersten Vorschlag zu verwenden. Andernfalls verwenden Sie den zweiten Vorschlag, wenn Sie das Profilschema erweitern.

BEARBEITEN

aspnet_Profile ist die Standardtabelle - der Standard SqlProfileProvider speichert die Profildaten des Benutzers als serialisierte Eigenschaftstasche in aspnet_Profile, weshalb es kein separates gibt aspnet_ProfileData Tisch auch.

Dieser Ansatz ermöglicht eine einfache Anpassung des Profilschemas für verschiedene Anwendungen, ohne dass Änderungen an der zugrunde liegenden Datenbank erforderlich sind, und ist die optimalste Lösung für ein Framework wie .NET.Der Nachteil besteht darin, dass SQL Server überhaupt keinen einfachen Zugriff auf diese Daten hat, sodass es viel schwieriger ist, die Profildaten des Benutzers mithilfe von T-SQL und satzbasierter Logik zu indizieren, zu aktualisieren und abzufragen.

Der häufigste Ansatz, den ich gesehen habe, um diese Einschränkung zu beseitigen, besteht darin, den Standard zu erweitern SqlProfileProvider um in eine benutzerdefinierte Profildatentabelle zu schreiben, die bestimmte Spalten für anwendungsspezifische Profileigenschaften enthält.Diese Tabelle hat natürlich eine 1:1-Beziehung zur Tabelle aspnet_Profile und verfügt daher über einen Fremdschlüssel, wie oben angegeben.

Die Rolle des erweiterten Anbieters besteht darin, beim Schreiben des Profils bestimmte Profileigenschaften in Spalten hochzustufen und beim Abrufen des Profils die Spalten einzulesen.

Auf diese Weise können Sie Speicherlösungen je nach Bedarf kombinieren, solange Ihr erweiterter Anbieter weiß, wie er auf die Standardimplementierung zurückgreifen kann, wenn er nichts von einer bestimmten Eigenschaft „weiß“.

Ich denke immer, dass es am besten ist, die Standard-Mitgliedschaftstabellen so zu belassen, wie sie sind, und sie bei Bedarf durch neue Tabellen mit entsprechenden Fremdschlüsseln zu erweitern, dann den entsprechenden Anbieter in Unterklassen zu unterteilen und die Anbietermethoden mit Ihrer eigenen Implementierung zu überschreiben (wobei Sie nach Möglichkeit die Basisimplementierung aufrufen). ).