Du skulle behöva utlösare för att "automatiskt" infoga posten i en separat tabell.
Att infoga posten i UserPrivacy med en separat fråga skulle vara det vanligaste sättet att implementera detta.
Om det är en en-till-en-relation, kan du lägga den i samma tabell för fler enkla frågor (ingen koppling krävs).
Beslut, beslut ...
Med ett ett-till-(noll till ett) förhållande finns det fler faktorer att ta hänsyn till.
Om UserPrivacy-tabellen är stor kan det vara vettigt att lägga den i en separat tabell för att spara utrymme. Detta skulle också vara mer normaliserat.
Om du ofta frågade något som "Ge mig alla användare som inte har PrivacyData", kan det vara vettigt att lägga det i en separat tabell. Eftersom index inte inkluderar NULL-värden (som standard), skulle det vara snabbare att göra en JOIN till en separat tabell. Naturligtvis är arbetet runt att använda ett annat värde än NULL för att representera "inga sekretessinställningar", men låg kardinalitet påverkar också prestandan negativt. Separata tabeller skulle vara bäst i det här fallet.
Om integritetsdata uppdaterades ofta, men inte användardata, skulle separata tabeller förhindra radlås på användartabellen och uppdateringar är snabbare på mindre tabeller, vilket kan förbättra prestandan.
Om du ofta behövde användarsekretessdata utan användardata, eller vice versa, kanske du vill separera dem.
Ändå kan detta vara för tidig optimering. Du kanske bara vill separera dem om de bättre matchar dina modeller. Tänk på hur enkelt det är att hålla det i samma tabell jämfört med frågorna om prestanda, storlek och läsbarhet.
Om förhållandet var ett-till-(noll till många) skulle du självklart vilja ha en separat tabell, men för ett-till-(noll till ett) är det valfritt.
Äntligen...
Var inte rädd för att skilja dem åt, så länge det finns en anledning.