Таблица для каждого типа объекта или отдельная таблица с множеством столбцов: что является самым быстрым? - PullRequest
1 голос
/ 09 марта 2009

Я должен хранить в базе данных четыре вида объектов в базе данных. Эти объекты имеют одинаковые атрибуты:

  • Имя (varchar2).
  • Описание (varchar2).
  • Файл (двоичный блоб).

Возможно, я могу использовать таблицу для хранения этих объектов, добавив столбец для определения типа объекта, но мне нужно хранить много объектов (> 1 000 000 или более).

Мой вопрос: какой сценарий лучше улучшить производительность? Таблица для хранения всех объектов или таблица для каждого типа объектов.

Я собираюсь использовать SQL Server 2005 или 2008.

Ответы [ 5 ]

5 голосов
/ 09 марта 2009

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

Добавьте столбец типа в вашу таблицу, и обслуживание и ваши запросы будут проще.

2 голосов
/ 09 марта 2009

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

Также следует с подозрением относиться к любому полю, называемому «описание», оно имеет неприятный запах, что указывает на недостаточное моделирование. Это имеет тенденцию использоваться как ловушка для всех отсутствующих атрибутов. Я не сторонник моделирования, но многие полезные структуры могут быть похоронены таким образом. Например, однажды мне пришлось добавить некоторые функции в базу данных продукта, которая выполняла некоторую обработку на основе «утверждения территории». Но не было никакого атрибута одобрения территории ??? после общения с пользователями выяснилось, что они хранят данные о территориях в поле описания, используя разработанную ими систему специальных кодов.

2 голосов
/ 09 марта 2009

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

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

Если вы решили разбить таблицу, становится сложнее выполнять запросы по нескольким типам или добавлять новый тип позже.

С другой стороны, если вам никогда не требуется выполнять запросы к нескольким типам (а имя не является уникальным для всех типов объектов), нет необходимости хранить их в одной таблице.

Я заметил, что у вас нет столбца типа. Вы, вероятно, должны иметь один, если вам нужно разделить четыре типа. Или это можно сделать, просто взглянув на имя?

Является ли имя первичным ключом? Размер таблиц очень мало влияет на производительность при поиске по первичному ключу.

0 голосов
/ 09 марта 2009

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

0 голосов
/ 09 марта 2009

Создайте одну главную справочную таблицу с именем и идентификатором для различных типов объектов. Затем создайте зависимую таблицу с идентификатором вместо имени. Вы можете иметь одну таблицу и разделить ее горизонтально в соответствии с типом объекта (id).

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...