Con lo que estás luchando es con la partición vertical. Esta es una técnica de diseño de base de datos física para mejorar el rendimiento. Al igual que con cualquier técnica de diseño de base de datos física, su aplicabilidad depende de las consultas específicas que está intentando optimizar y si esta técnica las optimizará. Desde un punto de vista lógico, si estos nuevos campos dependen de la clave candidata para su entidad, entonces son hechos al respecto que pertenecen a ella. Primero, debe asegurarse de comprender completamente la dependencia funcional de estos nuevos campos en sus claves candidatas para verificar que realmente son hechos sobre las visitas diarias a la página. Si lo son, decidir dividirlos en otra tabla es una optimización del rendimiento que solo debe hacerse si logra sus objetivos de rendimiento.
En general, la partición vertical es útil si consulta estas nuevas columnas con poca frecuencia y claramente de las otras columnas en la tabla original. Al colocar esas columnas en otra tabla que comparte la misma PK que su tabla existente, puede consultarla directamente cuando desee esas nuevas columnas y obtener un rendimiento mucho mayor, ya que tendrá muchas más filas por página en el disco para esta nueva tabla ya que todas las columnas de la tabla original no se colocarán en esas filas. Sin embargo, si siempre consulta estas columnas junto con las columnas de la tabla original, una partición vertical no tendría mucho sentido, ya que siempre tendrá que unir externamente para obtenerlas. Las páginas de las tablas en el disco entran en el grupo de búferes de un DBMS de forma independiente, nunca se unen previamente, y para que la unión tenga que suceder con cada ejecución de consulta, incluso si los datos están anclados en el grupo de búferes. En este escenario, convertirlas en columnas NULABLES en la tabla original permitiría al motor de almacenamiento DBMS almacenarlas de manera eficiente cuando NULL y eliminar la necesidad de unirse en la recuperación.
Me parece que su caso de uso es el último y agregarlos como NULLABLE a su tabla original es el camino a seguir. Pero al igual que con todo lo demás en el diseño de bases de datos, depende, y para tomar la decisión correcta, necesita conocer su carga de trabajo esperada y de qué depende tomar una buena decisión. Un buen ejemplo de un caso de uso adecuado para la partición vertical sería un panel de búsqueda de personas, en el que su aplicación tiene información muy rara sobre una persona en la que alguien podría querer buscar, pero rara vez lo hace. Si coloca esa información en una tabla diferente, tiene algunas buenas opciones para el rendimiento. Puede escribir la búsqueda para que tenga 2 consultas, una que use la información principal, siempre poblada para buscar (como apellido o ssn) solamente, y uno que se une externamente a la información poblada con poca frecuencia solo cuando se solicita para la búsqueda. O podría aprovechar el optimizador DBMS si es lo suficientemente inteligente como para reconocer para un conjunto dado de variables de host que la combinación externa no es necesaria y no la realizará, y por lo tanto solo tiene que crear 1 consulta.
¿Qué plataforma DBMS estás usando? La forma en que la plataforma maneja el almacenamiento de columnas NULL, optimiza su consulta, así como la disponibilidad de soporte de columnas dispersas (SQL Server tiene esto) afectará la decisión. En última instancia, recomendaría probar ambos diseños en un entorno de prueba con datos de tamaño de producción y carga de trabajo y ver cuál logra mejor sus objetivos de rendimiento.