Лучше иметь сотни столбцов или разбить на несколько таблиц?

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

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

будут ли какие-либо преимущества производительности для разделения вещей? Похоже, что запрос таблицы с несколькими десятками столбцов, вероятно, будет быстрее, чем запрос с сотнями столбцов.

есть ли у кого-нибудь опыт в таких вещах? Я использую Oracle для этого проекта, хотя это-то я вероятно, столкнуться с базами данных в будущем, поэтому ответы для любой базы данных будут оценены.

8
database-design

6 ответов

Я думаю, что нам нужно знать больше о вашем дизайне, чтобы ответить правильно. Например, мне любопытно, что может быть много столбцов, связанных с неисправностями, много (разных), связанных с замятиями и т. д. (Не является ли затор просто своего рода неисправностью?)

ваш дизайн нормализован? Предположительно, у вас нет столбцов типа "jam1", "jam2" и т. д.?!

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

  • все / большинство записей имеют статистику всех типов? Да => одна таблица, нет => много
  • вам часто нужно запрашивать статистику всех типов вместе? Да => одна таблица, нет => много
  • вы поддерживаете все различные статистики вместе на одном экране? Да => одна таблица, нет => много
  • вы, вероятно, попадете в какие-либо ограничения базы данных, например, Макс 1000 столбцов на таблицу?

каким бы путем вы ни пошли, вы можете использовать представления, чтобы представить альтернативную структуру для удобства разработчика:

  • одна таблица: много просмотров, которые выбирают статистику определенных типов
  • многие таблицы: представление, которое объединяет все таблицы вместе

обновление

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

create table machines (machine_id ... primary key, ...);
create table machine_stats 
   ( machine_id references machines
   , stat_group -- 'jams', 'malfunctions' etc.
   , stat_name  -- 'under the hood', 'behind the door' etc.
   , stat_count 
   );

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

10

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

Если вы можете уменьшить количество столбцов, вы можете уменьшить общий объем передаваемых данных и, следовательно, повысить производительность на нескольких уровнях. Например, если у вас есть запись, содержащая 1000 байт данных, и вы хотите изменить 1 байт для каждой записи, вы рискуете получить и сохранить 999 байтов без необходимости. Это влияет на производительность.

4

нормализация гарантирует, что вы не повторяете данные в свои схемы.

есть ограничения на то, как далеко вы должны идти, конечно. Соединения для 7 или более таблиц не являются исполнительными.

но один стол монстра? Я бы порвал с ним.

1

вы имеете в виду 100s типов статистики?

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

остерегайтесь, однако, что EAV спорный: некоторые говорят, что это" запах кода " и типичная ошибка новичка; другие говорят, что это полезно иногда (или редко), но зависит от (указания и наличия) хорошей поддержки метаданных.

1

мне не нравятся таблицы со слишком большим количеством столбцов. Один из вариантов, который вы можете рассмотреть, - сохранить статистику в виде строк в таблице статистики:

CREATE TABLE Statistics (id AS INTEGER PRIMARY KEY, statusType As VarChar,
statusValue As Float);

затем вы просто добавляете новую строку для каждого отслеживаемого состояния. Это намного чище с точки зрения БД, но это делает получение данных сложнее для отчетов.

1

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

machine
id
name
description

status_flag
id
caption

machine_history
machine_id
status_flag_id
information

тогда вы можете делать такие вещи, как: выберите count (distinct machine_id) из machine_history, где status_flag_id = 23 и информация

единственное, что информационное поле в таблице machine_history может содержать числа или символы. Если это так, я бы создал два информационных поля, чтобы вы не препятствовали производительности.

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

0