Не, това прави връзката "едно към нула или едно". Това ли всъщност ви трябва?
Акода , тогава вашето "второ решение" е по-добро:
- по-просто е,
- заема по-малко място за съхранение (и следователно прави кеша „по-голям“)
- по-малко индекси за поддържане, което е от полза за манипулирането на данни,
- и (тъй като използвате InnoDB) естествено клъстери данните, така че потребителите, които са близо един до друг, също ще имат своите акаунти, съхранявани близо един до друг, което може да е от полза за локализиране на кеша и определени видове сканиране на диапазон.
BTW, ще трябва да направите accounts.id обикновено цяло число (не автоматично увеличение), за да работи това.
Аконе , вижте по-долу...
Е, „най-добрият“ е претоварена дума, но „стандартното“ решение би било същото като във всяка друга база данни:поставете и двата обекта (потребител и акаунт във вашия случай) в една и съща физическа таблица.
Теоретично можете да правите кръгови FK между двата PK, но това ще изисква отложено ограничения за разрешаване на проблема с пиле и яйце, които за съжаление не се поддържат от MySQL.
Нямам много практически опит с този конкретен инструмент за моделиране, но предполагам, че това е, защото е „едно към много“, където „много“ страна е ограничена до 1, като го прави уникален. Моля, не забравяйте, че „много“ не означава „1 или много“, това означава „0 или много“, така че „ограничената“ версия наистина означава „0 или 1“.
Не само в разходите за съхранение за допълнителното поле, но и за вторичния индекс. И тъй като използвате InnoDB, който винаги клъстерира таблици , внимавайте, че вторичните индекси са дори по-скъпи в клъстерираните таблици, отколкото в таблици, базирани на heap.
InnoDB изисква индекси на външни ключове.
