Sollte ich den Benutzernamen oder die ID des Benutzers verwenden, um authentifizierte Benutzer in ASP.NET zu referenzieren

So, in meiner einfachen learning-website, die ich mit dem eingebauten ASP.NET Authentifizierung-system.

Ich füge jetzt eine user-Tabelle zu speichern Zeug, wie seine Postleitzahl, Geburtsdatum etc. Meine Frage ist:

  1. In der neuen Tabelle, sollte der Schlüssel sein, der Benutzer-name (string) oder die Benutzer-ID ist die GUID suchen Nummer, die Sie verwenden in der asp_ tables.
  2. Wenn die beste Praxis ist die Verwendung von hässlichen guid, wer weiß, wie um es zu bekommen? es scheint nicht zugänglich sein, so einfach wie der name (System.Web.HttpContext.Current.User.Identity.Name)
  3. Wenn Sie vorschlagen, ich benutze weder (nicht die guid noch die Felder für den Benutzernamen zur Verfügung gestellt von ASP.NET Authentifizierung), dann wie mache ich es mit ASP.NET die Authentifizierung? Eine option, die ich mag, ist die Verwendung der E-Mail-Adresse des Benutzers, wie login, aber wie soll ich das machen ASP.NET system-Authentifizierung verwenden, eine E-Mail-Adresse statt eines Benutzernamens? (oder es gibt nichts zu tun, es ist einfach mich zu entscheiden, ich "kenne" userName ist eigentlich ein E-Mail-Adresse?

Bitte beachten Sie:

  • Ich bin nicht gefragt, wie bekommen die eine GUID .NET, ich bin nur Bezugnahme auf die userID Spalte in der asp_ tables als guid.
  • Der Benutzername ist einzigartig in ASP.NET die Authentifizierung.

InformationsquelleAutor der Frage csmba | 2008-08-07

  1. 12

    Ich würde vorschlagen, mit dem Benutzernamen als Primärschlüssel in der Tabelle, wenn der Benutzername einzigartig sein, es gibt ein paar gute Gründe, dies zu tun:

    1. Der Primärschlüssel wird ein clustered index und damit der Suche nach einem Nutzer-details über Ihre Benutzernamen werden sehr schnell.
    2. Wird es aufhören, zu doppelten Usernamen angezeigt
    3. Sie nicht haben, um sorgen über die Verwendung von zwei verschiedenen Stücke der Informationen (Benutzername oder guid)
    4. Wird es, code zu schreiben viel einfacher, da Sie nicht mit lookup zwei bits von Informationen.

    InformationsquelleAutor der Antwort GateKiller

  2. 31

    Sollten Sie verwenden einige eindeutige Kennung, die GUID, die Sie erwähnen, oder einige andere auto-generierten Schlüssel. Allerdings sollte diese Zahl nie für den Benutzer sichtbar sein.

    Einen riesigen Vorteil dabei ist, dass alle Ihre code arbeiten können auf der Benutzer-ID, sondern der name des Benutzers ist nicht wirklich an Sie gebunden. Dann kann der user ändern Ihren Namen (die ich gefunden habe, nützlich auf Webseiten). Dies ist besonders nützlich, wenn Sie E-Mail-Adresse als Benutzer-login..., was sehr bequem für die Nutzer (dann werden Sie nicht daran denken müssen, 20 IDs im Falle Ihrer gemeinsamen Benutzer-ID ist ein beliebter).

    InformationsquelleAutor der Antwort Mike Stone

  3. 23

    Sollten Sie die Benutzer-id.
    Es ist die ProviderUserKey Eigenschaft von MembershipUser. 

    Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

    InformationsquelleAutor der Antwort palmsey

  4. 5

    Ich würde verwenden eine Benutzer-id. Wenn Sie möchten, verwenden Sie einen Benutzernamen, den Sie gehen, um die zu "username ändern" - Funktion sehr teuer.

    InformationsquelleAutor der Antwort jdelator

  5. 3

    Ich Stimme mit Palmsey,
    Obwohl es scheint einen kleinen Fehler in seinem code:

    Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

    sollte

    Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());

    InformationsquelleAutor der Antwort Schprit

  6. 3

    Ich würde sagen, verwenden die Benutzer-id, so dass Benutzernamen können noch verändert werden, ohne die Primärschlüssel. Ich würde auch die username-Spalte eindeutig sein, um halt doppelte Benutzernamen.

    Wenn Sie vor allem die Suche nach username anstatt UserID, dann stellen Sie Username einen gruppierten index und legen Sie den Primärschlüssel werden nicht gruppiert. Dies wird Ihnen den schnellsten Zugang bei der Suche nach Benutzernamen, wenn Sie jedoch hauptsächlich auf der Suche nach Benutzerkennungen, dann lassen Sie den gruppierten index.

    Edit : Das wird auch besser passen mit der aktuellen ASP.Net die Mitgliedschaft in Tabellen als auch die UserID als Primärschlüssel.

    InformationsquelleAutor der Antwort Gavin

  7. 3

    Dieser ist alt, aber ich möchte einfach Menschen, die finden, diese zu beachten, ein paar Dinge:

    1. Dem aspnet-Mitgliedschaft-Datenbank WIRD optimiert, wenn es um den Zugriff auf Benutzer-Datensätze. Der clustered index seek (optimal) in der sql server wird verwendet, wenn ein Datensatz gesucht wird, mithilfe loweredusername und applicationid. Das macht sehr viel Sinn, da wir nur den angegebenen Benutzernamen zu gehen, wenn der Benutzer sendet zuerst, Ihre Anmeldeinformationen einzugeben.

    2. Den guid userid geben Sie eine größere Größe index als int, aber das ist nicht wirklich wichtig, weil wir oft nur abrufen 1 Datensatz (user) zu einem Zeitpunkt und in Bezug auf die Fragmentierung, die Anzahl der liest in der Regel die großartige überwiegt die Anzahl der Schreibvorgänge und änderungen in der Benutzer-Tabelle - Menschen einfach nicht update, die info oft.

    3. den regsql-Skript erstellt das aspnet-Mitgliedschaft-Tabellen können bearbeitet werden, so dass anstelle der Verwendung von NEWID als Standard für die Benutzer-id, es kann die Verwendung von NEWSEQUENTIALID() liefert eine bessere Leistung (ich habe profiliert).

    4. Profil. Jemand, die Schaffung einer "neuen Lern-website" sollte nicht versuchen, das Rad neu zu erfinden. Eine der websites, für die ich gearbeitet habe verwendet ein out-of-the-box version des aspnet-Mitgliedschaft Tabellen (ohne die schrecklich-Profil-system) und die Benutzer-Tabelle, die fast 2 Millionen Nutzer-Datensätze. Selbst bei einer so hohen Anzahl von Datensätzen, wählt die waren noch schneller, weil, wie ich sagte, um zu beginnen mit, das Datenbank-Indizes fokussieren auf loweredusername+applicationid zu Registrierungsvorgang clustered index seek für diese Aufzeichnungen und generell, wenn sql ist dabei ein clustered index seek zu finden, 1 record, Sie haben keine Probleme, auch mit einer grossen Anzahl von Aufzeichnungen, sofern Sie nicht hinzufügen von Spalten zu Tabellen und starten Sie ziehen wieder zu viel Daten.

    5. Gedanken über eine guid in diesem system, für mich, basierend auf der tatsächlichen Leistung und die Benutzerfreundlichkeit des Systems, ist eine vorzeitige Optimierung. Wenn Sie ein int für Ihre userid, aber das system führt die sub-optimale Abfragen, weil Ihre benutzerdefinierten index design etc. das system wird nicht gut skalieren. Die Microsoft-Jungs haben generell eine gute Arbeit mit dem aspnet-Mitgliedschaft db und es gibt viele mehr produktive Dinge zu konzentrieren, als die änderung der userId int.

    InformationsquelleAutor der Antwort user1038019

  8. 2

    Ich würde eine auto-increment Zahl in der Regel ein int.

    Sie wollen, um die Größe der Taste, die so klein wie möglich. Dies hält den index der kleinen und Vorteile für alle foreign keys als gut. Additonally Sie sind nicht eng Kopplung der Daten-design zu externen Daten (dies gilt für das aspnet-GUID).

    In der Regel GUIDs nicht machen guter Primärschlüssel, da Sie groß und fügt geschehen kann, bei der potentiell jeder Seite Daten innerhalb der Tabelle anstatt auf der letzten Seite Daten. Die wichtigste Ausnahme ist, wenn Sie ausgeführt werden mutilple replizierten Datenbanken. GUIDs sind sehr nützlich für die Schlüssel in diesem Szenario, aber ich vermute, Sie haben nur eine Datenbank, so ist dies kein problem.

    InformationsquelleAutor der Antwort John Hunter

  9. 1

    Wenn du gehst zu sein mit LinqToSql für die Entwicklung, würde ich empfehlen, mit einem Int als Primärschlüssel. Ich hatte schon viele Probleme, wenn ich hatte Beziehungen aufgebaut aus nicht-Int-Felder, auch wenn die nvarchar(x), Feld, hatte Einschränkungen machen es zu einem einzigartigen Gebiet.

    Ich bin mir nicht sicher, ob dies ein bekannter bug in LinqToSql oder was, aber ich habe Probleme mit es auf ein Aktuelles Projekt und ich hatte zu tauschen PKs und FKs auf mehrere Tabellen.

    InformationsquelleAutor der Antwort Otto

  10. 0

    Ich Stimme mit Mike Stone. Ich würde auch vorschlagen, nur mit einer GUID in der Veranstaltung, die Sie gehen, um eine enorme Menge an Daten. Ansonsten, eine einfache auto-increment-integer (Id) - Spalte ausreichen.

    Wenn Sie brauchen GUID .NET schön genug, dass man durch einen einfachen...

    Dim guidProduct As Guid = Guid.NewGuid()

    oder

    Guid guidProduct = Guid.NewGuid();

    InformationsquelleAutor der Antwort Dillie-O

  11. 0

    Ich bin einverstanden mit Mike Stone auch. Meine Firma hat vor kurzem eine neue Benutzer-Tabelle für externe Kunden (im Gegensatz zu internen Benutzer, die Authentifizierung über LDAP). Für die externen Benutzer, entschieden wir uns, speichern Sie die GUID als Primärschlüssel und speichern Sie den Benutzernamen als varchar mit unique-constraints, die auf das Feld Benutzername ein.

    Auch, wenn Sie gehen, um zu speichern das Kennwort-Feld, ich empfehle das speichern der Passwörter als gesalzene, gehashte Binär in der Datenbank. Auf diese Weise, wenn jemand hack Ihrer Datenbank, Sie würden keinen Zugang zu Ihrem Kunden-Passwörter.

    InformationsquelleAutor der Antwort proudgeekdad

  12. 0

    Ich würde verwenden Sie die guid in meinem code und wie bereits erwähnt ein E-Mail-Adresse als Benutzername. Es ist, nachdem alle, ist schon einzigartig und unvergesslich für die Benutzer. Vielleicht sogar Graben, den guid - (v. fraglich).

    Jemand erwähnte, mit einem gruppierten index auf die GUID, wenn diese verwendet wurde, die in Ihrem code. Ich möchte vermeiden, vor allem, wenn die Einsätze sind hoch; der index neu erstellt werden jedes mal, wenn Sie einen Datensatz EINFÜGEN. Gruppierten Indizes arbeiten sowie auf auto-increment-IDs, obwohl, weil neue Datensätze angefügt werden nur.

    InformationsquelleAutor der Antwort iWeasel

Schreibe einen Kommentar