Soll ich den Benutzernamen oder die Benutzer-ID verwenden, um auf authentifizierte Benutzer in ASP.NET zu verweisen?

  • Daher verwende ich in meiner einfachen Lernwebsite das integrierte ASP.NET-Authentifizierungssystem.

    Ich füge jetzt eine Benutzertabelle hinzu, um Dinge wie ZIP, DOB usw. zu speichern. Meine Frage ist:

    1. In der neuen Tabelle sollte der Schlüssel der Benutzername (die Zeichenfolge) oder die Benutzer-ID sein, bei der es sich um die GUID-Nummer handelt, die sie in asp_ tables verwenden.
    2. Wenn es die beste Methode ist, diese hässliche Guid zu verwenden, weiß jemand, wie man sie bekommt? Es scheint nicht so leicht zugänglich zu sein wie der Name (System.Web.HttpContext.Current.User.Identity.Name)
    3. Wenn Sie vorschlagen, dass ich weder (guid noch die userName-Felder der ASP.NET-Authentifizierung) verwende, dann tun Sie dies Mache ich das mit ASP.NET-Authentifizierung? Eine Option, die ich mag, ist die Verwendung der E-Mail-Adresse des Benutzers als Login. Wie kann ich jedoch veranlassen, dass das ASP.NET-Authentifizierungssystem eine E-Mail-Adresse anstelle eines Benutzernamens verwendet? (oder es gibt nichts zu tun, ich entscheide einfach, dass ich weiß, dass "userName" eigentlich eine E-Mail-Adresse ist?

    Bitte beachten Sie:

    • Ich frage nicht nach, wie eine GUID in .NET abgerufen wird. Ich beziehe mich lediglich auf die Spalte userID in asp_ tables als guid.
    • Der Benutzername ist in der ASP.NET-Authentifizierung eindeutig.
    17 December 2015
    Víctor Gómez
11 answers
  • Sie sollten eine eindeutige ID verwenden, entweder die erwähnte GUID oder einen anderen automatisch generierten Schlüssel. Diese Zahl sollte jedoch für den Benutzer niemals sichtbar sein.

    Ein großer Vorteil davon ist, dass der gesamte Code mit der Benutzer-ID funktionieren kann, der Name des Benutzers ist jedoch nicht wirklich gebunden dazu Der Benutzer kann dann seinen Namen ändern (was ich auf Websites als nützlich empfunden habe). Dies ist besonders nützlich, wenn Sie die E-Mail-Adresse als Benutzer-Login verwenden ... was für Benutzer sehr praktisch ist (dann müssen sie sich nicht 20 IDs merken, falls ihre allgemeine Benutzer-ID beliebt ist).

    07 August 2008
    Mike Stone
  • Sie sollten die UserID verwenden. Dies ist die ProviderUserKey-Eigenschaft von MembershipUser.

     Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
     
    07 April 2010
    palmsey
  • Ich würde vorschlagen, den Benutzernamen als Primärschlüssel in der Tabelle zu verwenden, wenn der Benutzername eindeutig sein soll. Dafür gibt es einige gute Gründe:

    1. Der Primärschlüssel ist ein gruppierter Index. Die Suche nach Benutzerdetails über ihren Benutzernamen erfolgt sehr schnell.
    2. Dadurch werden doppelte Benutzernamen nicht angezeigt
    3. Sie müssen sich keine Gedanken über die Verwendung von zwei verschiedenen Informationen machen (Benutzername oder guid).
    4. Das Schreiben von Code wird viel einfacher, da Sie nicht nach zwei suchen müssen Informationen.
    07 August 2008
    GateKiller
  • Ich würde eine Benutzer-ID verwenden. Wenn Sie einen Benutzernamen verwenden möchten, wird die Funktion "Benutzername ändern" sehr teuer.

    07 August 2008
    jdelator
  • Ich stimme mit Palmsey überein. Obwohl es einen kleinen Fehler in seinem Code gibt:

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

    sollte sein

     Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
     
    06 May 2009
    Schprit
  • Ich würde sagen, verwenden Sie die UserID, damit Benutzernamen immer noch geändert werden können, ohne den Primärschlüssel zu beeinflussen. Ich würde auch die Spalte Benutzername angeben, um eindeutig zu sein, um doppelte Benutzernamen zu stoppen.

    Wenn Sie hauptsächlich nach Benutzername und nicht nach UserID suchen, machen Sie Username zu einem gruppierten Index und legen Sie fest, dass der Primärschlüssel nicht gruppiert ist. Dadurch erhalten Sie den schnellsten Zugriff bei der Suche nach Benutzernamen. Wenn Sie jedoch hauptsächlich nach UserIds suchen, belassen Sie dies als Clustered-Index.

    Bearbeiten: Dies passt auch besser zu den aktuellen ASP.Net-Mitgliedschaftstabellen, da sie auch die UserID als Primärschlüssel verwenden.

    06 May 2009
    Gavin
  • Ich würde eine automatisch ansteigende Nummer verwenden, normalerweise ein Int.

    Sie möchten die Schlüsselgröße so klein wie möglich halten. Dadurch bleibt Ihr Index klein und auch Fremdschlüssel profitieren. Außerdem koppeln Sie das Datendesign nicht eng mit externen Benutzerdaten (dies gilt auch für die aspnet-GUID).

    Im Allgemeinen sind GUIDs keine guten Primärschlüssel Große und Einfügungen können auf jeder Datenseite in der Tabelle und nicht auf der letzten Datenseite auftreten. Die Hauptausnahme davon ist, wenn Sie mehrfach replizierte Datenbanken ausführen. GUIDs sind in diesem Szenario für Schlüssel sehr nützlich, aber ich schätze, Sie haben nur eine Datenbank, daher ist dies kein Problem.

    27 August 2008
    John Hunter
  • Wenn Sie LinqToSql für die Entwicklung verwenden, würde ich empfehlen, einen Int als Primärschlüssel zu verwenden. Ich hatte viele Probleme, als ich Beziehungen aus Nicht-Int-Feldern aufgebaut hatte, selbst wenn das Feld nvarchar (x) Einschränkungen hatte, um es zu einem eindeutigen Feld zu machen.

    I ' Ich bin nicht sicher, ob dies ein bekannter Fehler in LinqToSql ist oder was, aber ich hatte Probleme mit einem aktuellen Projekt und musste PKs und FKs an mehreren Tabellen austauschen.

    08 August 2008
    Otto
  • Ich würde die Guid in meinem Code und wie bereits erwähnt eine E-Mail-Adresse als Benutzernamen verwenden. Immerhin ist es für den Benutzer bereits einzigartig und einprägsam. Vielleicht sogar die Guid aufgeben (v. Debateable).

    Jemand erwähnte die Verwendung eines Clustered-Index für die GUID, falls dies in Ihrem Code verwendet wurde. Ich würde dies vermeiden, besonders wenn INSERTs hoch sind; Der Index wird jedes Mal neu erstellt, wenn Sie einen Datensatz einfügen. Clustered-Indizes funktionieren gut für Auto-Inkrement-IDs, da nur neue Datensätze angehängt werden.

    06 May 2009
    iWeasel
  • Ich stimme Mike Stone zu. Ich würde auch vorschlagen, eine GUID nur dann zu verwenden, wenn Sie eine enorme Datenmenge verfolgen. Andernfalls reicht eine einfache, inkrementierende Ganzzahl (Id) -Spalte aus.

    Wenn Sie die GUID benötigen, ist .NET so hübsch, dass Sie durch eine einfache ...

     Dim guidProduct As Guid = Guid.NewGuid()
     

    oder

     Guid guidProduct = Guid.NewGuid();
     
    07 August 2008
    Dillie-O