Вы боретесь с вертикальным разделением. Это метод проектирования физической базы данных для повышения производительности. Как и в случае любого физического метода проектирования баз данных, его применимость зависит от конкретных запросов, которые вы пытаетесь оптимизировать, и от того, будет ли этот метод их оптимизировать. С логической точки зрения, если эти новые поля зависят от ключа-кандидата для вашей сущности, то это факты о ней, которые принадлежат ей. Во-первых, вы должны убедиться, что полностью понимаете функциональную зависимость этих новых полей от ключей-кандидатов, чтобы убедиться, что они действительно являются фактами ежедневных просмотров страниц. Если это так, то решение разделить их на другую таблицу - это оптимизация производительности, которую следует выполнять только в том случае, если она достигает ваших целей производительности.
В общем случае вертикальное разбиение полезно, если вы будете запрашивать эти новые столбцы не так часто и в отличие от других столбцов исходной таблицы. Поместив эти столбцы в другую таблицу, которая использует тот же PK, что и существующая таблица, вы можете запросить ее напрямую, когда захотите эти новые столбцы, и получить гораздо большую пропускную способность, поскольку у вас будет гораздо больше строк на страницу на диске для этой новой таблицы поскольку все столбцы из исходной таблицы не будут сидеть в этих строках. Однако, если вы всегда будете запрашивать эти столбцы вместе со столбцами в исходной таблице, вертикальный раздел не будет иметь особого смысла, поскольку для их получения вам всегда будет необходимо внешнее соединение. Страницы из таблиц на диске попадают в буферный пул СУБД независимо друг от друга, предварительно не объединяясь, и поэтому это соединение должно происходить при каждом выполнении запроса, даже если данные закреплены в пуле буферов. В этом сценарии создание из них столбцов NULLABLE в исходной таблице позволило бы механизму хранения СУБД эффективно хранить их при NULL и исключить необходимость объединения при извлечении.
Мне кажется, что ваш вариант использования является последним, и добавление их как NULLABLE в исходную таблицу - это путь. Но, как и во всем остальном в проектировании баз данных, это зависит от ситуации, и для принятия правильного решения вам необходимо знать ожидаемую рабочую нагрузку и то, от чего зависит правильный выбор. Одним хорошим примером правильного варианта использования вертикального разделения может служить панель поиска людей, где в вашем приложении есть очень редко заполняемая информация о человеке, по которому кто-то может искать, но редко делает. Если вы поместите эту информацию в другую таблицу, у вас есть несколько хороших вариантов для производительности. Вы можете написать поиск так, чтобы у вас было 2 запроса - один, который использует основную, всегда заполненную информацию для поиска (например, фамилия или ssn), и тот, который внешний, присоединяется к очень редко заполняемой информации только тогда, когда она запрашивается для поиска. Или вы можете воспользоваться оптимизатором СУБД, если он достаточно умен, чтобы распознавать для заданного набора переменных хоста, что внешнее соединение не требуется и не будет его выполнять, и, следовательно, вам нужно всего лишь создать 1 запрос.
Какую платформу СУБД вы используете? Способ, которым платформа обрабатывает хранилище NULL-столбцов, оптимизирует ваш запрос, а также доступность поддержки разреженных столбцов (так есть в SQL Server), повлияет на решение. В конечном итоге я бы порекомендовал опробовать оба проекта в тестовой среде с объемными данными и рабочей нагрузкой и выяснить, какие из них лучше достигают ваших целей производительности.