Сколько полей в таблице «слишком много»?

нет произвольного ограничения; достаточно, чтобы выполнить работу - хорошее практическое правило

если у вас есть лучший дизайн БД, предложите его

если вам нужен более подробный отзыв, опубликуйте схему

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

Подумайте о данных, которые вы будете там хранить. Вероятно, что многие из этих полей будут NULL? Какова вероятность того, что эти поля изменятся (например, будут добавлены новые)?

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

refs (id, title, refType)
-- title of the reference, and what type of reference it is

fieldDef (id, fieldName, refType, dataType)
-- name of the field, which reference types it applies to, and
-- what type of data is stored in these fields (ISDN number, date, etc)

fields (refId, fieldId, value)
-- where you actually add data to the references.

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

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

Количество полей обычно не является проблемой, но вы хотите убедиться, что ваша база данных правильно норализована. Третья нормальная форма - хорошее начало.

Если вам нужно спросить: «Слишком много полей в этой таблице?» Тогда, наверное, есть.

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

Я бы сказал, что для вашей БД «Эксперт» необходим курс по проектированию баз данных. И я бы посоветовал вам освежить его в памяти ... это может только помочь вам в карьерном росте :)

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

Например, если у вас есть таблица с адресами, включаете ли вы в эту таблицу поля города, штата и почтового индекса? Или вы включаете только одно поле, которое «указывает» на запись в отдельной таблице для этих значений? Отдельная таблица будет содержать уникальные комбинации города, штата и почтового индекса. Разделение данных на две таблицы приводит к уменьшению объема хранимых данных (скорее всего, но не абсолютному), но к некоторой дополнительной сложности при выполнении запросов к базе данных. Теперь вам нужно иметь дело с двумя таблицами вместо одной. Но, с другой стороны, он намного чище и (вероятно) намного меньше.

Реальный ответ - это нормально оставлять почтовые данные города-государства в адресной таблице при правильных обстоятельствах. Или вы можете захотеть «нормализовать» это. Оба в порядке.

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

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

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

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

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

Самый очевидный признак того, что таблица требует нормализации, - это поля, оканчивающиеся целыми числами: CouponCode1, CouponCode2, CouponCode3 ... вы понимаете. Однако, как всегда, будут исключения из правил.

Руководство партизана по нормализации по умолчанию:

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

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

Когда группы полей явно недостаточно используются в таблице, может быть разумным разделить эту группу полей в другой таблице с отношением 0-1 между основной таблицей и «вспомогательной» таблицей.

По соображениям безопасности также часто предлагалось (давным-давно: я думаю, это была моя первая книга о реляционных базах данных, впервые опубликованная в 197?) Разделить конфиденциальную информацию в другой таблице с тем же соотношением 0-1 между main и суб. После этого можно было легко ограничить доступ пользователей к «вспомогательной» таблице. Такой конфигурацией теперь можно легко управлять с помощью представлений.

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

OLTP

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

IMO 30 столбцов - это слишком много.

Для меня не более 10% моих OLTP-таблиц имеют большое количество (> 10) столбцов.

OLAP

Теперь, если вы собираетесь создать структуру измерений / отчетов, некоторые люди могут посчитать таблицу из 30 столбцов узкой.