Necesitaría disparadores para insertar "automáticamente" el registro en una tabla separada.
Insertar el registro en UserPrivacy con una consulta separada sería la forma más común de implementar esto.
Si se trata de una relación uno a uno, ponerlo en la misma tabla permite realizar consultas más sencillas (no se requiere unión).
Decisiones, Decisiones...
Con una relación de uno a (cero a uno), hay más factores a considerar.
Si la tabla UserPrivacy es grande, podría tener sentido colocarla en una tabla separada para ahorrar espacio. Esto también estaría más normalizado.
Si a menudo consultaba algo como "Dame todos los usuarios que no tienen datos de privacidad", entonces podría tener sentido ponerlo en una tabla separada. Dado que los índices no incluyen valores NULL (de forma predeterminada), sería más rápido hacer un JOIN en una tabla separada. Por supuesto, la solución consiste en utilizar un valor que no sea NULL para representar "sin configuración de privacidad", pero la baja cardinalidad también afecta negativamente al rendimiento. Mesas separadas serían lo mejor para este caso.
Además, si los datos de privacidad se actualizaron con frecuencia, pero no los datos del Usuario, las tablas separadas evitarían los bloqueos de fila en la tabla del Usuario y las actualizaciones son más rápidas en las tablas más pequeñas, lo que podría mejorar el rendimiento.
Si a menudo necesitaba los datos de UserPrivacy sin UserData, o viceversa, es posible que desee separarlos.
Aún así, esto podría ser una optimización prematura. Es posible que desee separarlos si coinciden mejor con sus modelos. Considere la simplicidad de mantenerlo en la misma tabla frente a los problemas de rendimiento, tamaño y legibilidad.
Si la relación fuera uno a (cero a muchos), obviamente querrías una tabla separada, pero para uno a (cero a uno), es opcional.
Finalmente...
No tengas miedo de separarlos, siempre que haya una razón.
