Wir haben eine Website mit Subdomains wie:
Und jede Domain und Subdomain hat eine andere Datenbank, so:
Was haben Sie versucht?
Im Moment haben wir für die einmalige Anmeldung geplant, Benutzer auf unserer Hauptseite umzuleiten, um sich anzumelden.
Während die Auftragsbearbeitung in Sub-Domains die UserID von der Haupt-DB bezieht und in der Orders-Tabelle der jeweiligen Sub-Domain speichert.
Zu Berichtszwecken speichern wir UserID ohne FK constraint in der Tabelle Orders , da wir eine separate Datenbank haben.
Ich kann hier
Wird das StackExchange-Netzwerkprofil in einer separaten Datenbank gespeichert?
Ich sehe hier Die Benutzertabelle jeder Site hat AccountId des StackExchange-Netzwerkprofils.
Ein Beispiel:
Hier ist Nick Craver Netzwerkprofil mit der ID: 7598
Sein Profil in der History-Site hat eine Account-ID, die mit derselben ID verknüpft ist: 7598 check this Abfrage.
Ich kann die Accounts -Tabelle nirgends in dumbs anzeigen , also wurde AccountId gespeichert? Und wie wird SSO an mehreren Standorten mit AccountId ?
Meine Frage: Brauchen wir eine einzelne Benutzertabelle in der Main DB oder müssen wir separate Benutzertabellen für die Datenbank der Subdomain und Link Main DB UserID , aber nicht FK constraint erstellen? Welches ist das beste Design für eine Shopping-Site?
Jede Hilfe wäre großartig.
Die von Ihnen erwähnte Benutzer-ID ist nur in einer bestimmten Benutzertabelle in einer einzelnen DB identisch. Es ist eigentlich kein Bezeichner für einen Nutzer in Ihrer Domain. Um Benutzer in mehreren Datenbanken zu identifizieren, benötigen Sie für jeden Benutzer eine ID auf Domänenebene. Eine einfache Möglichkeit besteht darin, der Benutzerklasse (Tabelle) eine weitere Eigenschaft (Spalte) mit der Bezeichnung UID oder etwas Ähnliches hinzuzufügen, nämlich die globale eindeutige ID (GUID), siehe Ссылка ) und verwenden Sie sie als ID auf Domänenebene, um Benutzer anstelle von UserId zu identifizieren. Auf diese Weise können Sie Benutzerinformationen in mehreren Datenbanken in Ihrer Domäne frei speichern. Also:
1] Sie müssen eine separate Benutzertabelle in allen drei Datenbanken haben, da es keine referenzielle Integrität des Fremdschlüssels gibt. Wenn eine Datenbank ausfällt, werden andere Domänen ausgeführt. Die Datenbankverwaltung benötigt mehr Wartung aber Leistung wird nicht behindern.
Alternativ können Sie den folgenden Datenbankplan erstellen.
1] Behalten Sie eine Datenbank für alle drei Domänen (eine Hauptdomäne und zwei Unterdomänen)
2] Erstellen Sie eine Benutzertabelle mit zwei Status-Flags für food_order, fashion_order
3] Erstellen Sie eine Auftragstabelle für Lebensmittel und Mode separat
4] Es gibt drei Möglichkeiten, dass Benutzer bestellen i) Essen oder ii) Mode oder iii) Essen / Mode beide.
5] Aktualisiere Statusflagge wie auf Bestellung entweder Essen oder Mode oder Essen / Mode beide.
Hier ist der Kompromiss: Wenn Ihre Datenbank ausfällt, geht Ihre gesamte Website aus. So behalten Sie ein sehr gutes Disaster-Recovery-Modell der Datenbank bei.
Einige Optionen:
Speichern Sie Ihre Benutzer nur in der Hauptdatenbank. Dann ...
Speichern Sie Ihre Benutzerinformationen in allen DBs. Normalerweise erhalten Sie die Informationen zu den anderen DBs mit einem der ...
Mit Option 1 würde Ihre Haupt-DB alle anderen Websites beeinträchtigen. Mit Option 2 sind die Nicht-Haupt-DBs ziemlich im Cache gespeicherte Kopien, und Sie müssen mit der Ungültigmachung des Cache umgehen.
Welche Option Sie auswählen, hängt hauptsächlich von Ihren spezifischen Geschäftsanforderungen ab.
Ich denke, wie Sie in Ihrer Frage angefangen haben, ist Ihre beste Wette.
Am besten ist es, wenn Sie eine Benutzertabelle und drei Konfigurationstabellen haben. Die Tabelle "one users" wird mit der SSO-Funktionalität verknüpft, mit der Benutzer, ihr gesamtes Profil und ihre Anmeldeinformationen überprüft werden. Jeder Dienst / jede Website, die / der für die Domäne irrelevant ist, die das SSO des Verbunds verwendet und die Cookies des Benutzers überprüft. I.e. tue so, als wäre alles gleich, außer dass du Google Web Federation für SSO verwendest. Die Daten, die in Google gespeichert sind, interessieren Sie nicht wirklich (außer vielleicht gibt es Feld, das Sie tun, möglicherweise Benutzername, usw.). Egal, in welcher Domäne Sie sich befinden, die erste Sache, die Sie tun, ist, einen Anruf zu SSO zu machen und sehen, ob der Benutzer bereits angemeldet ist, wenn sie nicht direkt dort sind, und wenn sie fertig sind, erhalten sie eine Weiterleitung zurück zu Ihrer Subdomain.
Wenn sie eingeloggt sind, dann keine Weiterleitung, aber Sie erhalten das JWT-Token, das die Umwandlung von gespeicherten userIds (oder UID) in tatsächliche Informationen ermöglicht.
Sagen Sie zum Beispiel, dass ein eingeloggter Benutzer etwas von fashion.example.com kauft. Sie könnten Ihrer Tabelle orders eine Zeile hinzufügen, die zufällig eine Spalte namens "userId" enthält. Wenn diese Site auf der Startseite "Benutzer X bestellte Y" veröffentlichen möchte, nachdem Sie die Bestellung aus der Tabelle erhalten haben, rufen Sie den SSO-Dienst an, um ein JWT mit den Benutzerinformationen mithilfe des SSO-Tokens abzurufen. Wenn Sie aus irgendeinem Grund eine Konfiguration speichern möchten, die sich nach Subdomäne unterscheidet, erstellt diese Subdomain ihre eigene Tabelle "users" oder "configuration", und der Schlüssel wird mit der UID im SSO-Dienst verknüpft. Ob es eine eindeutige PK gibt, bleibt Ihnen überlassen (mit einem FX zur UID) oder wenn die PK die UID ist.
Damit können Sie die Domains vollständig voneinander trennen. Und lassen Sie Ihre Subdomain entscheiden, ob sie eine Tabelle "Benutzer" benötigt oder nicht.
TL; DR. Sie haben wirklich 4 Domains, nicht 3, behandeln sie als 1 SSO Authentifizierungsdomain und 3 Sites. Das SSO verfügt über die Authentifizierungstabelle, und jede Standortdomäne kann ggf. eine eigene Benutzertabelle haben. Diese Benutzertabelle würde einen FK für die SSO-Tabelle haben, ohne dass eine FX-Einschränkung durchgesetzt werden muss. (FK Constraint, wenn irgendwie durchgesetzt werden könnte, wäre tatsächlich schlecht, weil Sie nicht wollen, dass ein SSO-Dienst über die Subdomains wissen muss, wenn ein Benutzerkonto gelöscht werden sollte, die Tatsache, dass diese alle verschiedene Datenbanken sind, ist schon genial. )
Tags und Links sql-server architecture database-schema database-design