Сколько столбцов таблицы базы данных слишком много?

Question

Я взял на себя разработку проекта, в котором есть пользовательская таблица с более чем 30 столбцами.И плохо, что изменения и дополнения в столбцах продолжают происходить.

Это неправильно.

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

user
    id
    email

user_field
    id
    name

user_value
    id
    user_field_id
    user_id
    value

Answer 1

Делать не идти по маршруту ключ / значение.SQL не предназначен для этого, и он сделает извлечение реальных данных из вашей базы данных самообучением.(Примеры: индексы работают не очень хорошо. Объединения - это очень весело, когда вам нужно присоединиться только для того, чтобы получить данные, к которым вы присоединяетесь. Это продолжается.)

Пока данные нормализованы доПриличного уровня у вас не слишком много столбцов.

РЕДАКТИРОВАТЬ: Для ясности, есть некоторые проблемы, которые могут быть решены только с помощью маршрута ключ / значение.«Слишком много столбцов» не входит в их число.

Answer 2

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

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

Answer 3

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

Answer 4

Это часто называют EAV, и то, подходит ли это для вашей базы данных, зависит от множества факторов:

http://en.wikipedia.org/wiki/Entity-attribute-value_model

http://karwin.blogspot.com/2009/05/eav-fail.html

http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back

Слишком много столбцов на самом деле не один из них.

Answer 5

Если изменения и дополнения постоянны, то, возможно, вам нужно сесть и лучше определить требования. Теперь я не могу сказать, слишком ли много 30 столбцов, потому что это зависит от их ширины и от того, должны ли они быть перенесены в связанную таблицу. Например, если у вас есть поля, такие как phone1, phone2, phone 3, у вас есть беспорядок, который нужно разбить на связанную таблицу для user_phone. Или, если все ваши столбцы широкие (а общая ширина вашей таблицы шире, чем на страницах, в которых хранятся данные), а некоторые не так часто нужны для ваших запросов, они могут быть лучше в связанной таблице, которая имеет однозначный одно отношение. Я бы, вероятно, не сделал бы этого, если бы у вас не было реальной проблемы с производительностью.

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

Answer 6

Это на самом деле зависит от того, что вы пытаетесь сделать.