K „automatickému“ vložení záznamu do samostatné tabulky byste potřebovali spouštěče.
Vložení záznamu do UserPrivacy pomocí samostatného dotazu by bylo nejběžnějším způsobem implementace.
Pokud se jedná o vztah jedna ku jedné, její umístění do stejné tabulky umožňuje jednodušší dotazy (není nutné spojení).
Rozhodnutí, rozhodnutí...
U vztahu jedna ku (nula ku jedné) je třeba zvážit více faktorů.
Pokud je tabulka UserPrivacy velká, může mít smysl ji umístit do samostatné tabulky, abyste ušetřili místo. To by bylo také více normalizované.
Pokud jste se často dotazovali na něco jako „Dejte mi všechny uživatele, kteří nemají PrivacyData“, pak by mohlo mít smysl dát to do samostatné tabulky. Protože indexy neobsahují hodnoty NULL (ve výchozím nastavení), bylo by rychlejší provést JOIN do samostatné tabulky. Samozřejmě je možné použít jinou hodnotu než NULL k vyjádření „žádného nastavení soukromí“, ale nízká mohutnost také negativně ovlivňuje výkon. Pro tento případ by byly nejlepší samostatné tabulky.
Také pokud byla často aktualizována data o ochraně osobních údajů, ale nikoli data uživatele, samostatné tabulky by zabránily uzamčení řádků v tabulce uživatelů a aktualizace jsou rychlejší u menších tabulek, což může zlepšit výkon.
Pokud jste často potřebovali data UserPrivacy bez UserData nebo naopak, možná je budete chtít oddělit.
Přesto se může jednat o předčasnou optimalizaci. Možná je budete chtít oddělit, pokud lépe odpovídají vašim modelům. Zvažte jednoduchost udržování ve stejné tabulce oproti problémům s výkonem, velikostí a čitelností.
Pokud by byl vztah jedna ku-(nula k mnoha), samozřejmě byste chtěli samostatnou tabulku, ale pro 1 ku (nula ku jedné) je to volitelné.
Konečně...
Nebojte se je oddělit, pokud je k tomu důvod.