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

Question

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

BaseTable:
    Id
    NonOptionFields
OptionTable:
    Id
    OptionName
    OptionValue

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

Answer 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.

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

---

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

Answer 5

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

Answer 6

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

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

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

Answer 7

OLTP

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

ИМО 30 столбцов слишком много.

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

1012 * OLAP *

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

Answer 8

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

Answer 9

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

Answer 10

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

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

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