Когда стоит перенести столбцы из основной таблицы во вспомогательную таблицу?

Question

Скажем, у меня есть такая таблица:

  create table users (
   user_id int not null auto_increment,
   username varchar,
   joined_at datetime,
   bio text,
   favorite_color varchar,
   favorite_band varchar
   ....
 );

Скажем, что со временем все больше и больше столбцов - таких как favour_animal, favour_city и т. Д. - добавляются в эту таблицу.В конце концов, есть около 20 или более столбцов.

На данный момент я чувствую, что хочу переместить столбцы в отдельную таблицу user_profiles, чтобы я мог сделать select * from users без возврата большого числаобычно нерелевантных столбцов (например, favour_color).И когда мне нужно выполнить запрос по favour_color, я могу просто сделать что-то вроде этого:

select * from users inner join user_profiles using user_id where
user_profiles.favorite_color = 'red';

Хорошая идея - переместить столбцы из основной таблицы во «вспомогательную» таблицу?

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

select user_id, username, last_logged_in_at, etc. etc. from users;

Какие здесь вопросы производительности?

Answer 1

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

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

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

Answer 2

Одна вещь, которую никто больше не упомянул, это то, что часто бывает полезно иметь вспомогательную таблицу, если размер строки основной таблицы станет слишком большим. Прочитайте об ограничениях размера строки ваших конкретных баз данных в документации. Часто есть преимущества в производительности, если иметь менее широкие таблицы и перемещать поля, которые вы используете не так часто, в отдельную таблицу. Если вы решите создать вспомогательную таблицу с отношением «один к одному», убедитесь, что настроили отношение PK / FK для поддержания целостности данных и установите уникальный индекс или ограничение для поля FK, чтобы поддерживать отношение «один к одному» ,

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

Answer 3

Я бы сказал, что лучший вариант - правильно нормализованные таблицы и также , чтобы запрашивать только те столбцы, которые вам нужны.

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

Answer 4

Общее правило, которое применяется к этому (называемое нормализацией), состоит в том, что таблицы группируются по отдельным объектам / объектам / концепциям, и что каждый столбец (поле) в этой таблице должен описывать некоторый аспект этого объекта

В вашем примере кажется, что favour_color описывает (или принадлежит) пользователя. Иногда полезно перенести данные во вторую таблицу: когда становится ясно, что эти данные на самом деле описывают вторую сущность. Например: вы начинаете сбор вашей базы данных user_id, name, email, and zip_code. Затем в какой-то момент главный исполнительный директор решает, что он также хотел бы получить street_address. На этом этапе была сформирована новая сущность, и вы могли бы концептуально рассматривать ваши данные в виде двух таблиц:

user: userid, name, email
address: steetaddress, city, state, zip, userid(as a foreign key)

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

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

Answer 5

Не отменяйте нормализацию, если у вас нет веских причин для этого.

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

Answer 6

Старайтесь не привыкать к использованию SELECT * FROM ... Если ваше приложение становится большим и вы запрашиваете таблицу users для разных вещей в разных частях вашего приложения, то когда вы добавляете favorite_animal, вы становитесь более может сломать какое-то место, которое использует SELECT *. Или, по крайней мере, это место теперь получает неиспользуемые поля, что замедляет его.

Выберите данные, которые вам нужны. Он автоматически документирует следующему человеку, что именно вы пытаетесь сделать с этим кодом.

Answer 7

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

Вы не должны полагаться на использование SELECT * по разным причинам (Google google).

Answer 8

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

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

Answer 9

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