Дизайн базы данных: новый стол и новые столбцы

(Предполагалось, что это будет repost здесь из StackOverflow)

В настоящее время есть таблица .. и нужно начинать добавлять к ней новые столбцы данных. Не каждая запись (даже с новыми данными после добавления новых столбцов данных) будет иметь данные. Поэтому мне интересно, подходит ли это для новой таблицы, поскольку это действительно расширение некоторых строк данных и не относится к каждой строке.

Другими словами, поскольку для этих новых элементов данных будет много неиспользуемых столбцов, похоже, что это будет больше подходит для новой таблицы?

Первая таблица - это запись просмотров страниц (в настоящее время 2 миллиона записей)

- Я бы
- Айпи адрес
- просмотренные просмотры
- created_at timestamp
- Дата

для каждого IP-адреса, запись производится в день - и последовательные просмотры страниц добавляются к представлениям времени в день

дополнительное поле (ы) было бы предназначено для отслеживания точки начала (т. е. google analytics source /medium /campaign)

Не каждый визит будет иметь эту информацию. Im предположил бы, что около 10% строк будут иметь данные (как правило, только при первом посещении)

Основное использование данных - это атрибут, из которого люди пришли. Это может привести к более частому использованию (которое, кажется, поддается одной таблице)

Оцените обратную связь - при необходимости добавьте больше

35 голосов | спросил cgmckeever 25 Maypm12 2012, 16:56:53

3 ответа


23

То, с чем вы сражаетесь, - это вертикальное разбиение. Это физический метод проектирования базы данных для повышения производительности. Как и в любой физической технологии проектирования баз данных, ее применимость зависит от конкретных запросов, которые вы пытаетесь оптимизировать, и если этот метод будет их оптимизировать. С логической точки зрения, если эти новые поля зависят от ключа-кандидата для вашего объекта, то это факты об этом, которые принадлежат ему. Сначала вы должны убедиться, что вы полностью понимаете функциональную зависимость этих новых полей от ваших потенциальных ключей, чтобы убедиться, что они действительно являются фактами о ежедневных просмотрах страниц. Если они, решая разбить их на другую таблицу, это оптимизация производительности, которая должна выполняться только в том случае, если она достигает ваших целей производительности.

В общем, вертикальное разбиение полезно, если вы будете запрашивать эти новые столбцы нечасто и четко из других столбцов в исходной таблице. Поместив эти столбцы в другую таблицу, которая использует тот же PK, что и ваша существующая таблица, вы можете запросить его напрямую, когда вам нужны эти новые столбцы, и получите гораздо больше сквозных, поскольку у вас будет еще больше строк на странице на диске для этой новой таблицы так как все столбцы из исходной таблицы не будут сидеть на этих строках. Однако, если вы всегда будете запрашивать эти столбцы вместе с столбцами в исходной таблице, то вертикальный раздел не будет иметь большого смысла, поскольку вы всегда будете иметь внешнее соединение, чтобы получить их. Страницы из таблиц на диске поступают в буферный пул СУБД независимо друг от друга, никогда не присоединяются и поэтому соединение должно выполняться с каждым выполнением запроса, даже если данные закреплены в пуле буферов. В этом случае создание столбцов NULLABLE в исходной таблице позволит механизму хранения СУБД эффективно сохранять их при NULL и исключать необходимость объединения при поиске.

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

Какую платформу СУБД вы используете? То, как платформа обрабатывает хранилище столбцов NULL, оптимизирует ваш запрос, а также доступность разреженной поддержки столбцов (это имеет место SQL Server), повлияет на решение. В конечном итоге я бы рекомендовал попробовать оба проекта в тестовой среде с данными о производстве и рабочей нагрузкой и увидеть, что лучше достигает ваших целей производительности.

ответил Todd Everett 25 Maypm12 2012, 18:14:24
10

Лично я склоняюсь к добавлению столбцов в существующую таблицу. Новая таблица на самом деле ничего не покупает:

  • вы не сохраняете много места, потому что значения NULL в исходной таблице не занимают места, а новой таблице нужен какой-то идентификатор, который в любом случае компенсирует любую экономию.
  • ваши запросы становятся более сложными ... where newcolumn is not null становится left outer join

В единственной таблице это просто означает, что размер вашей строки может варьироваться от страницы к странице, но это не должно влиять на многие из ваших существующих страниц, особенно если ваш кластерный индекс находится на монотонно увеличивающемся столбце (идентификатор или дата /время) .

ответил Aaron Bertrand 25 Maypm12 2012, 17:25:07
4

Учитывая предоставленную вами информацию, и с общей целью стандартизации, я бы, вероятно, просто добавил столбцы с нулевым значением, но вы не указали достаточно информации о том, как данные будут использоваться, чтобы знать, что лучший способ модель данных.

В зависимости от того, как вы действительно используете эти данные, вам может потребоваться рассмотреть другую модель данных. Если вы размещаете эти данные для отчетности, вы можете захотеть взглянуть на размерную модель, которая может быть более эффективной для определенных типов отчетов - например, анализ времени суток хорошо работает с разграничением даты и времени.

Для ответа на аналитические вопросы, такие как «то, что является самым популярным временем дня для посещений из таких кампаний, как X» или «в какой день кампании мы видим наибольшее количество посещений в час», один столбец данных и времени (но это может быть даже разделено на реляционную модель), и есть много случаев, когда вы можете рассматривать IP-адрес как измерение (возможно, с некоторыми географическими данными в снежинке).

ответил Cade Roux 25 Maypm12 2012, 19:39:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132