レコードを別のテーブルに「自動的に」挿入するには、トリガーが必要です。
別のクエリを使用してレコードをUserPrivacyに挿入するのが、これを実装する最も一般的な方法です。
1対1の関係の場合は、同じテーブルに配置すると、より単純なクエリが可能になります（結合は必要ありません）。
決定、決定...
1対（0対1）の関係では、考慮すべき要素がさらにあります。
UserPrivacyテーブルが大きい場合は、スペースを節約するために別のテーブルに配置するのが理にかなっている場合があります。これもより正規化されます。
「PrivacyDataを持っていないすべてのユーザーを教えてください」のようなクエリを頻繁に行う場合は、別のテーブルに配置するのが理にかなっているかもしれません。インデックスには（デフォルトでは）NULL値が含まれていないため、別のテーブルにJOINを実行する方が高速です。もちろん、回避策は「プライバシー設定なし」を表すためにNULL以外の値を使用することですが、カーディナリティが低いとパフォーマンスに悪影響を及ぼします。この場合は、個別のテーブルが最適です。
また、プライバシーデータが頻繁に更新され、ユーザーデータは更新されない場合、個別のテーブルを使用すると、ユーザーテーブルの行ロックが防止され、小さいテーブルでは更新が高速になり、パフォーマンスが向上する可能性があります。
UserDataなしでUserPrivacyデータが頻繁に必要な場合、またはその逆の場合は、それらを分離することをお勧めします。
それでも、これは時期尚早の最適化である可能性があります。モデルとの適合性が高い場合は、それらを分離することをお勧めします。パフォーマンス、サイズ、読みやすさの問題と比較して、同じテーブルに保持することの単純さを考慮してください。
関係が1対（0対多）の場合は、明らかに別のテーブルが必要ですが、1対（0対1）の場合は、オプションです。
最後に...
理由がある限り、それらを分離することを恐れないでください。