Ще ви трябват тригери, за да "автоматично" вмъкнете записа в отделна таблица.
Вмъкването на записа в UserPrivacy с отделна заявка би било най-често срещаният начин за прилагане на това.
Ако е връзка едно към едно, поставянето й в същата таблица позволява по-прости заявки (не се изисква присъединяване).
Решения, решения...
При връзка едно към (нула към едно) има повече фактори, които трябва да се вземат предвид.
Ако таблицата UserPrivacy е голяма, тогава може да има смисъл да я поставите в отделна таблица, за да спестите място. Това също би било по-нормализирано.
Ако често задавате запитвания за нещо като „Дайте ми всички потребители, които нямат PrivacyData“, тогава може да има смисъл да го поставите в отделна таблица. Тъй като индексите не включват NULL стойности (по подразбиране), би било по-бързо да направите JOIN към отделна таблица. Разбира се, работата за заобикаляне е да се използва стойност, различна от NULL, за да представлява "без настройки за поверителност", но ниската мощност също се отразява негативно на производителността. За този случай най-добре биха били отделни таблици.
Освен това, ако данните за поверителност се актуализират често, но не и потребителските данни, отделни таблици биха предотвратили заключването на редове в таблицата с потребители, а актуализациите са по-бързи в по-малките таблици, което може да подобри производителността.
Ако често имате нужда от данните за UserPrivacy без UserData или обратно, може да искате да ги разделите.
Все пак това може да е преждевременна оптимизация. Може просто да искате да ги разделите, ако по-добре отговарят на вашите модели. Помислете за простотата да го държите в една и съща таблица в сравнение с проблемите с производителността, размера и четливостта.
Ако връзката беше едно към (нула към много), очевидно бихте искали отделна таблица, но за едно към (нула към едно) не е задължително.
Най-накрая...
Не се страхувайте да ги разделите, стига да има причина.
