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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

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

Ответ 4

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

Подумайте о данных, которые вы будете хранить там. Вероятно, что многие из этих полей будут 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.

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

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

Ответ 5

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

если у вас лучший дизайн db, предложите

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

OLTP

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

Количество столбцов IMO 30 слишком велико.

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

OLAP

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

Ответ 10

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

В таблице должен быть первичный ключ и не более одного столбца.
Прерывать правило номер 1 только так часто, как требуется.

Ответ 11

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

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

Ответ 12

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

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