Ciò con cui stai lottando è il partizionamento verticale. Questa è una tecnica di progettazione di database fisici per migliorare le prestazioni. Come con qualsiasi tecnica di progettazione di database fisici, la sua applicabilità dipende dalle query specifiche che si sta tentando di ottimizzare e se questa tecnica le ottimizzerà. Da un punto di vista logico, se questi nuovi campi dipendono dalla chiave candidata per la tua entità, allora sono fatti su di essa che appartengono ad essa. Per prima cosa dovresti assicurarti di comprendere appieno la dipendenza funzionale di questi nuovi campi dalle tue chiavi candidate per verificare che siano realmente fatti sulle visualizzazioni di pagina quotidiane. In tal caso, decidere di dividerli in un'altra tabella è un'ottimizzazione delle prestazioni che dovrebbe essere eseguita solo se raggiunge i propri obiettivi di prestazione.
In generale, il partizionamento verticale è utile se si interrogano queste nuove colonne raramente e distintamente dalle altre colonne nella tabella originale. Inserendo quelle colonne in un'altra tabella che condivide lo stesso PK della tabella esistente, è possibile interrogarlo direttamente quando si desidera quelle nuove colonne e ottenere un throughput molto maggiore poiché si avranno molte più righe per pagina sul disco per questa nuova tabella poiché tutte le colonne della tabella originale non saranno posizionate su quelle righe. Tuttavia, se interrogherai sempre queste colonne insieme alle colonne nella tabella originale, allora una partizione verticale non avrebbe molto senso poiché dovrai sempre unire esterno per ottenerle. Le pagine dalle tabelle su disco entrano nel pool buffer di un DBMS in modo indipendente, mai pre-unito, e in tal modo l'unione dovrà avvenire ad ogni esecuzione della query anche se i dati sono bloccati nel pool di buffer. In questo scenario, renderle NULLABILI nella tabella originale consentirebbe al motore di archiviazione DBMS di memorizzarle in modo efficiente quando NULL ed eliminare la necessità di unirsi al recupero.
Mi sembra che il tuo caso d'uso sia il secondo e aggiungerli come NULLABLE alla tabella originale è la strada da percorrere. Ma come per qualsiasi altra cosa nella progettazione del database, dipende e per prendere la decisione giusta è necessario conoscere il carico di lavoro previsto e da cosa dipende la scelta. Un buon esempio di un caso d'uso corretto per il partizionamento verticale potrebbe essere un pannello di ricerca di una persona, in cui l'applicazione contiene alcune informazioni popolate molto raramente su una persona su cui qualcuno potrebbe voler cercare ma lo fa raramente. Se metti queste informazioni in una tabella diversa hai alcune buone opzioni per le prestazioni. Puoi scrivere la ricerca in modo da avere 2 query: una che utilizza solo le informazioni principali, sempre popolate per la ricerca (come il cognome o SSN), e uno che si unisce alle informazioni popolate molto raramente solo quando sono richieste per la ricerca. Oppure potresti sfruttare l'ottimizzatore DBMS se è abbastanza intelligente da riconoscere per un dato set di variabili host che il join esterno non è necessario e non lo eseguirà, e quindi devi solo creare 1 query.
Quale piattaforma DBMS stai usando? Il modo in cui la piattaforma gestisce l'archiviazione delle colonne NULL, ottimizza la query, così come la disponibilità del supporto delle colonne sparse (SQL Server ha questo) influenzerà la decisione. In definitiva, consiglierei di provare entrambi i progetti in un ambiente di test con dati di dimensioni di produzione e carico di lavoro e di vedere quale raggiunge meglio i tuoi obiettivi prestazionali.