Nie, to tworzy relację „jeden do zera lub jeden”. Czy tego właśnie potrzebujesz?
Jeśli tak , wtedy Twoje „drugie rozwiązanie” jest lepsze:
- to prostsze,
- zajmuje mniej miejsca (i dlatego sprawia, że pamięć podręczna jest „większa”)
- ma mniej indeksów do utrzymania, co sprzyja manipulacji danymi,
- i (ponieważ używasz InnoDB) naturalnie klastry dane, dzięki czemu użytkownicy znajdujący się blisko siebie będą mieli również swoje konta przechowywane blisko siebie, co może przynieść korzyści w lokalizacji pamięci podręcznej i niektórych rodzajach skanowania zasięgu.
BTW, musisz zrobić accounts.id zwykłą liczbę całkowitą (nie auto-inkrementację), aby to zadziałało.
Jeśli nie , patrz poniżej...
Cóż, „najlepszy” to przeciążone słowo, ale „standardowe” rozwiązanie byłoby takie samo, jak w każdej innej bazie danych:umieść obie encje (w twoim przypadku użytkownika i konto) w tej samej tabeli fizycznej.
Teoretycznie mógłbyś utworzyć okrągłe FK między dwoma PK, ale wymagałoby to odroczenia ograniczenia do rozwiązania problemu kurczaka i jajka, które niestety nie są obsługiwane przez MySQL.
Nie mam dużego praktycznego doświadczenia z tym konkretnym narzędziem do modelowania, ale domyślam się, że to dlatego, że jest to „jeden do wielu”, gdzie „wiele” strony zostało ograniczone do 1, czyniąc go wyjątkowym. Pamiętaj, że „wiele” nie oznacza „1 lub wiele”, oznacza „0 lub wiele”, więc wersja „ograniczona” naprawdę oznacza „0 lub 1”.
Nie tylko w kosztach przechowywania dodatkowego pola, ale także indeksu dodatkowego. A ponieważ używasz InnoDB, która zawsze grupuje tabele , strzeż się, że indeksy dodatkowe są nawet droższe w tabelach klastrowych niż w tabelach opartych na stercie.
InnoDB wymaga indeksów na kluczach obcych.
