Я взял на себя разработку проекта, в котором есть пользовательская таблица с более чем 30 столбцами. А плохо то, что изменения и дополнения в столбцах продолжают происходить.
Это неправильно.
Должен ли я настаивать на перемещении дополнительных полей во вторую таблицу в качестве значений и создании третьей таблицы, в которой хранятся имена этих столбцов?
user
id
email
user_field
id
name
user_value
id
user_field_id
user_id
value
не используйте путь ключ/значение. SQL не предназначен для обработки этого, и он сделает получение фактических данных из вашей базы данных упражнением в самоистязании. (Примеры: индексы не работают должным образом. Соединения — это очень весело, когда вам нужно присоединиться только для того, чтобы получить данные, к которым вы присоединяетесь. Это продолжается.)
Пока данные нормализованы до приличного уровня, у вас не будет слишком много столбцов.
РЕДАКТИРОВАТЬ: Чтобы было ясно, есть некоторые проблемы, которые можно решить только с помощью маршрута ключ/значение. «Слишком много столбцов» не является одним из них.
Трудно сказать, сколько слишком много. Это действительно очень субъективно. Я думаю, что вопрос, который вы должны задавать, состоит не в том, «Не слишком ли много столбцов?», а скорее в том, «Уместны ли эти столбцы здесь?» Я имею в виду, что если в вашей таблице User есть столбцы, которые не обязательно являются свойствами пользователя, то они могут и не принадлежать. Например, если у вас есть куча столбцов, в которых суммируется адрес пользователя, то, возможно, вы вытащите их в таблицу Address с FK в User.
Я бы по возможности избегал использования таблиц ключ/значение. Это может показаться простым способом сделать вещи расширяемыми, но на самом деле это просто боль в долгосрочной перспективе. Если вы обнаружите, что ваша схема меняется очень последовательно, вы можете подумать о том, чтобы установить какой-то контроль изменений, чтобы проверять изменения только для тех, которые необходимы, или перейти на другую технологию, которая лучше поддерживает хранилище без схемы, например NoSQL с MongoDB или CouchDB.
Его часто называют 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
Слишком много столбцов на самом деле не один из них.
Изменения и дополнения к таблице — это неплохо, если это означает, что они точно отражают изменения в ваших бизнес-требованиях.
Если изменения и дополнения происходят постоянно, возможно, вам нужно сесть и лучше определить требования. Теперь я не могу сказать, слишком ли много 30 столбцов, потому что это зависит от их ширины и от того, следует ли их переместить в связанную таблицу. Например, если у вас есть такие поля, как phone1, phone2, phone 3, у вас есть беспорядок, который нужно разделить на связанную таблицу для user_phone. Или, если все ваши столбцы широкие (и общая ширина вашей таблицы шире, чем страницы, на которых базы данных хранят данные) и некоторые из них не так часто нужны для ваших запросов, они могут быть лучше в связанной таблице, которая имеет отношение один к одному. одни отношения. Я бы, вероятно, не стал этого делать, если у вас нет реальной проблемы с производительностью.
Однако из всех возможных вариантов описанная вами модель EAV является худшей как с точки зрения ремонтопригодности, так и с точки зрения производительности. Очень сложно написать приличные запросы к этой модели.
Это на самом деле зависит от того, что вы пытаетесь сделать.
