Сколько столбцов слишком много столбцов?

Я заметил, что многие люди здесь цитируют таблицы с 20 + (я видел целых 55) столбцов в одной таблице. Теперь я не претендую на роль эксперта по дизайну базы данных, но я всегда слышал, что это ужасная практика. Когда я вижу это, я обычно предлагаю разбивать на две таблицы с отношением один к одному: один из которых содержит наиболее часто используемые данные, а другой - с наименее часто используемыми данными. Хотя в то же время существует возможная проблема производительности (меньше JOINs и таковых). Поэтому мой вопрос таков:

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

Что больше влияет на производительность: много столбцов с большим количеством NULL или меньше столбцов с большим количеством JOIN?

Ответ 1

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

Пока таблица normalized, нет никакого правила большого размера, кроме возможностей базы данных и необходимости оптимизации.

Ответ 2

Сколько столбцов слишком много столбцов?

Когда вы чувствуете, что это уже не имеет смысла или право добавить другой столбец.

В целом зависит от приложения.

Ответ 3

Я согласен с Одедом. Я видел таблицы с 500 столбцами в них, и все столбцы в них были в правильном месте. Просто рассмотрите количество фактов, которые, возможно, захотите сохранить о повседневном объекте, и вы скоро поймете, почему.

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

Ответ 4

odbc имеет предел символов 8000.... так что это физический предел, за которым все становится очень расстраивающим.

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

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

Ответ 5

По моему опыту, лучше иметь меньше объединений, поскольку они часто случаются слишком часто, особенно в большой базе данных. Пока ваши таблицы базы данных предназначены для хранения единого объекта (учащегося, учителя и т.д.), Это должно быть хорошо. Так что это будет представлено как объект в вашем коде позже. Итак, если вы разделили объект на несколько таблиц, вам придется использовать несколько соединений для заполнения вашего объекта позже. Также, если вы используете ORM для создания своего уровня доступа к данным (например, Linq в .Net), будет генерироваться отдельный класс для каждой таблицы (конечно, с отношениями между ними, но все же), и это будет сложнее использовать.

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

Каждый проект, над которым я работал, отличается, поэтому вы должны найти баланс для каждой истории.

Ответ 6

Что больше влияет на производительность: много столбцов с большим количеством NULL или меньше столбцов с большим количеством JOINs?

Это зависит исключительно от данных, которые вы храните, индексов, которые вы делаете, и так далее. Никто не может гарантировать, что вы работаете лучше другого, не зная, что вы храните. Как правило, правила нормализации "заставят" вас разделить данные на разные таблицы и пользовательские FKeys, если у вас большая таблица, но я не согласен, что она ВСЕГДА работает лучше, чем одна большая таблица. Вы можете завершить 6-7-уровневые соединения в десятках запросов, которые иногда вызывают ошибки, потому что гораздо больше шансов создать ошибку в более крупных запросах, чем в простых.

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

Ответ 7

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

В мире NO-SQL (например, cassandra/hbase) нет ограничений на количество столбцов, и на самом деле считается хорошей практикой иметь много столбцов. Это также связано с тем, как он хранится (без пробелов). Стоит при исследовании.

Ответ 8

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

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