Potrzebujesz wyzwalaczy, aby „automatycznie” wstawić rekord do osobnej tabeli.
Wstawienie rekordu do UserPrivacy za pomocą oddzielnego zapytania byłoby najczęstszym sposobem realizacji tego.
Jeśli jest to relacja jeden-do-jednego, umieszczenie jej w tej samej tabeli umożliwia prostsze zapytania (nie jest wymagane łączenie).
Decyzje, decyzje...
W przypadku relacji jeden do (zero do jednego) należy wziąć pod uwagę więcej czynników.
Jeśli tabela UserPrivacy jest duża, warto umieścić ją w osobnej tabeli, aby zaoszczędzić miejsce. Byłoby to również bardziej znormalizowane.
Jeśli często zadajesz pytanie typu „Daj mi wszystkich użytkowników, którzy nie mają PrivacyData”, sensowne może być umieszczenie ich w osobnej tabeli. Ponieważ indeksy nie zawierają wartości NULL (domyślnie), szybciej byłoby wykonać JOIN do oddzielnej tabeli. Oczywiście obejściem jest użycie wartości innej niż NULL do reprezentowania „braku ustawień prywatności”, ale niska kardynalność również negatywnie wpływa na wydajność. W tym przypadku najlepsze byłyby oddzielne tabele.
Ponadto, jeśli dane dotyczące prywatności były często aktualizowane, ale nie dane użytkownika, oddzielne tabele zapobiegłyby blokadzie wierszy w tabeli Użytkownik, a aktualizacje są szybsze w przypadku mniejszych tabel, co może poprawić wydajność.
Jeśli często potrzebowałeś danych UserPrivacy bez UserData lub odwrotnie, możesz je rozdzielić.
Mimo to może to być przedwczesna optymalizacja. Możesz po prostu je rozdzielić, jeśli lepiej pasują do twoich modeli. Rozważ prostotę trzymania go w tej samej tabeli w porównaniu z kwestiami wydajności, rozmiaru i czytelności.
Jeśli relacja byłaby jeden do (zero do wielu), oczywiście potrzebujesz oddzielnej tabeli, ale w przypadku relacji jeden do (zero do jednego) jest to opcjonalne.
Wreszcie...
Nie bój się ich rozdzielać, o ile jest ku temu powód.
