Nein, das macht die Relation "eins zu null oder eins". Brauchen Sie das wirklich?
Wenn ja , dann ist Ihre "zweite Lösung" besser:
- Es ist einfacher,
- benötigt weniger Speicherplatz (und macht daher den Cache "größer")
- Es müssen weniger Indizes gepflegt werden, was der Datenmanipulation zugute kommt
- und (da Sie InnoDB verwenden) natürlich Cluster die Daten, sodass Benutzer, die nahe beieinander liegen, ihre Konten auch nahe beieinander gespeichert haben, was der Cache-Lokalität und bestimmten Arten von Bereichsscans zugute kommen kann.
Übrigens müssen Sie accounts.id erstellen eine gewöhnliche Ganzzahl (keine automatische Erhöhung), damit dies funktioniert.
Wenn nein , siehe unten...
Nun, „am besten“ ist ein überladenes Wort, aber die „Standard“-Lösung wäre dieselbe wie in jeder anderen Datenbank:Legen Sie beide Entitäten (Benutzer und Konto in Ihrem Fall) in dieselbe physische Tabelle.
Theoretisch könnten Sie zirkuläre FKs zwischen den beiden PKs erstellen, aber das würde verzögert erfordern Beschränkungen, um das Henne-Ei-Problem zu lösen, die unter MySQL leider nicht unterstützt werden.
Ich habe nicht viel praktische Erfahrung mit diesem speziellen Modellierungswerkzeug, aber ich vermute, das liegt daran, dass es "eins zu vielen" ist, wobei die "viele" Seite auf 1 begrenzt wurde, indem es einzigartig gemacht wurde. Bitte denken Sie daran, dass "viele" nicht "1 oder viele" bedeutet, sondern "0 oder viele", also bedeutet die "gedeckelte" Version wirklich "0 oder 1".
Nicht nur im Speicheraufwand für das Zusatzfeld, sondern auch für den Sekundärindex. Und da Sie InnoDB verwenden, das immer Tabellen gruppiert , beachten Sie, dass sekundäre Indizes in geclusterten Tabellen noch teurer sind als in Heap-basierten Tabellen.
InnoDB erfordert Indizes auf Fremdschlüsseln.
