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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

Если к определенным объектам относятся только определенные поля, возможно, подумайте о том, чтобы поместить эти поля в другую таблицу. Кроме того, сохраняйте только основные, общие поля в одной таблице и дополнительную информацию в другой таблице, по одной строке в поле. Как I suggested для a different question (which might be helpful to you):

 
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, и, вероятно, не без оснований. Это вариант, не обязательно лучший вариант, но он по-прежнему работоспособный метод. Однако самый высокий проголосовавший ответ в вопросе, который я связал с ним, может быть лучшим решением.

---

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

Answer 3

Число полей, как правило, не является проблемой, но вы хотите, чтобы ваша база данных была правильно обновлена. Third normal form - хорошее начало.

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

BaseTable: 
    Id 
    NonOptionFields 
OptionTable: 
    Id 
    OptionName 
    OptionValue 

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

Answer 11

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

Answer 12

OLTP

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

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

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

OLAP

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