Wenn ich zwei Tabellen - Logins und Benutzer wie folgt:Wie wird bestimmt, wo der Fremdschlüssel in diesem Szenario platziert wird?
Logins
LoginIdNo
UserIdNo
HashedPassword
Users
UserIdNo
LoginIdNo
Username
Jeder Login „einen Benutzer“ und jeder Benutzer „hat einen Login“, aber die „gehört“ Which?
Ist es einfach ein Urteilsspruch oder gibt es eine klare Formel für die Bestimmung, wo der Fremdschlüssel liegen sollte?
Dies ist eine Eins-zu-Eins-Beziehung. Wo Sie den Fremdschlüssel setzen, entscheiden Sie in diesen Fällen wahrscheinlich über die Optionalität.
Gibt es einen bestimmten Grund, warum Sie diese in zwei Entitäten aufgeteilt haben? Ich bin kein großer Fan von Eins-zu-Eins-Mappings, insbesondere bei ORMs wie JPA, bei denen es schwierig ist, sie zu implementieren (wenn Sie den Primärschlüssel von einem als Fremdschlüssel zu einem anderen verwenden).
Was ist in Ihrem System der Unterschied zwischen einem Login und einem Benutzer?
Wenn die Anmeldung bei jeder Anmeldung eines Benutzers erfolgt (dh es handelt sich um einen Audit-Trail der Benutzeraktivität), haben Sie eine Eins-zu-viele-Beziehung zwischen Benutzer und Login und Login sollte einen UserID-Fremdschlüssel verwenden.
Aber in diesem Fall, wo der Benutzername in einer Tabelle und das Passwort in einem anderen ist und es eine Eins-zu-Eins-Beziehung zwischen den beiden gibt, müssen Sie fragen, warum sie getrennt sind.
Da ein Login niemals mehr als einem Benutzer zugeordnet wird (und umgekehrt), ist es eine willkürliche Entscheidung darüber, wie Sie die Beziehung definieren (und daher auch, wo Sie den Fremdschlüssel platzieren). Es sei denn, Sie auch andere Attribute (Firleds) oder verwenden Sie Rollen hinzufügen wollen, könnte es einfacher sein, einfach zu definieren, etwa so:
Users
UserIdNo
Username
HashedPassword
Es gibt zwei Unterschiede zwischen Login und Benutzer, an die ich gedacht habe. Eine davon ist, dass die Benutzertabelle viele andere Felder für Kontaktinformationen (Adresse, Telefon usw.) enthält. Die Logins-Tabelle wäre zwar datensparender, aber die Tabelle als Ganzes könnte unabhängig von meiner Anwendung eine Form der Verschlüsselung durchlaufen (ich bin mir nicht sicher, wie genau das geschehen würde). –
Ihr Audit-Trail-Beispiel ist ein guter Punkt. Umgekehrt, wenn für jede Bearbeitung der Benutzerdaten ein Audit-Trail erforderlich ist, wäre der Fremdschlüssel möglicherweise die LoginId, es sei denn, die Login-Informationen werden ebenfalls geprüft. Wenn Benutzer und Login Audit-Trails haben, bin ich mir nicht sicher funktioniert - in diesem Fall brauchen wir vielleicht auch eine UserAudit und LoginAudit Tabelle? –
@fraggle: Ich bevorzuge diese Unterscheidung als Person und Benutzer, was eine vernünftige Modellierungsentscheidung ist. Aber wenn Sie das täten, wären Benutzername und Passwort wahrscheinlich auf derselben Entität. – cletus