Сколько столбцов слишком много столбцов? [закрытый]

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

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

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

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

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

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

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

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

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

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

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

Когда вы чувствуете, что больше не имеет смысла или правильно добавлять еще один столбец.

Обычно зависит от приложения.

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

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

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