Вы боретесь с вертикальным разделением. Это метод проектирования физической базы данных для повышения производительности. Как и в случае любого физического метода проектирования баз данных, его применимость зависит от конкретных запросов, которые вы пытаетесь оптимизировать, и от того, будет ли этот метод их оптимизировать. С логической точки зрения, если эти новые поля зависят от ключа-кандидата для вашей сущности, то это факты о ней, которые принадлежат ей. Во-первых, вы должны убедиться, что полностью понимаете функциональную зависимость этих новых полей от ключей-кандидатов, чтобы убедиться, что они действительно являются фактами ежедневных просмотров страниц. Если это так, то решение разделить их на другую таблицу - это оптимизация производительности, которую следует выполнять только в том случае, если она достигает ваших целей производительности.
В общем случае вертикальное разбиение полезно, если вы будете запрашивать эти новые столбцы не так часто и в отличие от других столбцов исходной таблицы. Поместив эти столбцы в другую таблицу, которая использует тот же PK, что и существующая таблица, вы можете запросить ее напрямую, когда захотите эти новые столбцы, и получить гораздо большую пропускную способность, поскольку у вас будет гораздо больше строк на страницу на диске для этой новой таблицы поскольку все столбцы из исходной таблицы не будут сидеть в этих строках. Однако, если вы всегда будете запрашивать эти столбцы вместе со столбцами в исходной таблице, вертикальный раздел не будет иметь особого смысла, поскольку для их получения вам всегда будет необходимо внешнее соединение. Страницы из таблиц на диске попадают в буферный пул СУБД независимо друг от друга, предварительно не объединяясь, и поэтому это соединение должно происходить при каждом выполнении запроса, даже если данные закреплены в пуле буферов. В этом сценарии создание из них столбцов NULLABLE в исходной таблице позволило бы механизму хранения СУБД эффективно хранить их при NULL и исключить необходимость объединения при извлечении.
Мне кажется, что ваш вариант использования является последним, и добавление их как NULLABLE в исходную таблицу - это путь. Но, как и во всем остальном в проектировании баз данных, это зависит от ситуации, и для принятия правильного решения вам необходимо знать ожидаемую рабочую нагрузку и то, от чего зависит правильный выбор. Одним хорошим примером правильного варианта использования вертикального разделения может служить панель поиска людей, где в вашем приложении есть очень редко заполняемая информация о человеке, по которому кто-то может искать, но редко делает. Если вы поместите эту информацию в другую таблицу, у вас есть несколько хороших вариантов для производительности. Вы можете написать поиск так, чтобы у вас было 2 запроса - один, который использует основную, всегда заполненную информацию для поиска (например, фамилия или ssn), и тот, который внешний, присоединяется к очень редко заполняемой информации только тогда, когда она запрашивается для поиска. Или вы можете воспользоваться оптимизатором СУБД, если он достаточно умен, чтобы распознавать для заданного набора переменных хоста, что внешнее соединение не требуется и не будет его выполнять, и, следовательно, вам нужно всего лишь создать 1 запрос.
Какую платформу СУБД вы используете? Способ, которым платформа обрабатывает хранилище NULL-столбцов, оптимизирует ваш запрос, а также доступность поддержки разреженных столбцов (так есть в SQL Server), повлияет на решение. В конечном итоге я бы порекомендовал опробовать оба проекта в тестовой среде с объемными данными и рабочей нагрузкой и выяснить, какие из них лучше достигают ваших целей производительности.
Лично я склоняюсь к добавлению столбцов в существующую таблицу. Новый стол на самом деле ничего не покупает:
where newcolumn is not nullстановитсяleft outer joinВ одной таблице это просто означает, что размер вашей строки может варьироваться от страницы к странице, но это не должно влиять на многие из ваших существующих страниц, особенно если ваш кластерный индекс находится в монотонно увеличивающемся столбце (идентификатор или дата / время).
источник
Учитывая предоставленную вами информацию, а цель - просто общую нормализацию, я бы, вероятно, просто добавил пустые столбцы, но вы не дали достаточно информации о том, как данные будут использоваться, чтобы знать, как лучше всего моделировать данные. является.
В зависимости от того, как вы на самом деле используете эти данные, вы можете рассмотреть другую модель данных. Если вы помещаете эти данные в отчет, вы, возможно, захотите взглянуть на многомерную модель, которая может быть более эффективной для определенных типов отчетов - например, анализ времени дня хорошо работает с разделением измерения даты и времени.
Для ответов на аналитические вопросы, такие как «какое самое популярное время суток для посещений из таких кампаний, как X» или «в какой день кампании мы видим наибольшее количество посещений в час», один столбец времени данных не будет работать очень хорошо (но это даже можно разделить в реляционной модели), и во многих случаях вы можете рассматривать IP-адрес как измерение (возможно, с некоторыми географическими данными в снежинке).
источник