Что более эффективно: несколько таблиц MySQL или одна большая таблица?

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

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

Вот пример некоторых из моих структур таблиц:

• пользователи - UserId, имя пользователя, адрес электронной почты, зашифрованный пароль, дата регистрации, ip
• user_details - данные cookie, имя, адрес, контактные данные, принадлежность, демографические данные
• user_activity - публикации, последний онлайн, последний просмотр
• user_settings - настройки отображения профиля
• user_interests - переменные рекламного таргетинга
• user_levels - права доступа
• user_stats - хиты, счетчики

Изменить: я проголосовал за все ответы, все они содержат элементы, которые по сути отвечают на мой вопрос.

Большинство таблиц имеют соотношение 1: 1, что и было основной причиной их денормализации.

Возникнут ли проблемы, если таблица занимает более 100 столбцов, когда большая часть этих ячеек, вероятно, останется пустой?

Несколько таблиц помогают в следующих случаях / случаях:

(а) если разные люди собираются разрабатывать приложения с разными таблицами, имеет смысл разделить их.

(b) Если вы хотите предоставить разным людям разные полномочия для разных частей сбора данных, может быть удобнее разделить их. (Конечно, вы можете определить представления и соответствующим образом авторизовать их).

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

(d) Меньший размер следа может быть удобен при разработке приложений для сбора конкретных данных одной организации.

(e) Это возможность: то, что вы считали данными с одним значением, в будущем может оказаться действительно несколькими значениями. например, кредитный лимит на данный момент представляет собой поле с одним значением. Но завтра вы можете решить изменить значения как (дата от, дата до, значение кредита). Разделенные столы теперь могут пригодиться.

Я бы проголосовал за несколько таблиц с должным образом разделенными данными.

Удачи.

Объединение таблиц называется денормализацией.

Это может (а может и не помочь) сделать некоторые запросы (которые создают множество запросов JOIN), чтобы они выполнялись быстрее за счет создания ада обслуживания.

MySQLспособен использовать только JOINметод, а именно NESTED LOOPS.

Это означает, что для каждой записи в управляющей таблице MySQLнаходит соответствующую запись в управляемой таблице в цикле.

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

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

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

С другой стороны, адская эксплуатация гарантирована.

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

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

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

Связаны ли все эти таблицы 1-to-1? Например, будет ли каждая пользовательская строка иметь только одну соответствующую строку в user_statsили user_levels? Если так, возможно, имеет смысл объединить их в одну таблицу. Если же отношений нет 1 to 1 , вероятно, не имеет смысла объединять (денормализовать) их.

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

ETA:

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

Если вы посмотрите на то, как вы используете данные, я предполагаю, что вы обнаружите, что примерно 80% ваших запросов используют 20% этих данных, а остальные 80% данных используются только изредка. Объедините эти часто используемые 20% в одну таблицу и оставьте 80%, которые вы не часто используете, в отдельных таблицах, и вы, вероятно, получите хороший компромисс.

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

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

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

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

Я работал в телефонной компании, где было множество таблиц, и для получения данных могло потребоваться много соединений. Когда производительность чтения из этих таблиц была критической, тогда создавались процедуры, которые могли генерировать плоскую таблицу (т.е. денормализованную таблицу), которая не требовала объединений, вычислений и т.д., на которые могли бы указывать отчеты. Затем они использовались вместе с агентом сервера SQL для выполнения задания через определенные промежутки времени (т.е. еженедельный просмотр некоторой статистики будет запускаться один раз в неделю и так далее).

Почему бы не использовать тот же подход, который использует Wordpress, имея таблицу пользователей с базовой информацией о пользователе, которая есть у каждого, а затем добавляя таблицу «user_meta», которая может быть любой парой ключ-значение, связанной с идентификатором пользователя. Поэтому, если вам нужно найти всю метаинформацию для пользователя, вы можете просто добавить ее в свой запрос. Вам также не всегда нужно добавлять дополнительный запрос, если он не нужен для таких вещей, как вход в систему. Преимущество этого подхода также оставляет вашу таблицу открытой для добавления новых функций для ваших пользователей, таких как сохранение их дескрипторов Twitter или каждого отдельного интереса. Вам также не придется иметь дело с лабиринтом связанных идентификаторов, потому что у вас есть одна таблица, которая управляет всеми метаданными, и вы ограничите ее только одной связью вместо 50.

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

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

Я бы сказал, это зависит от того, что на самом деле означают другие таблицы. Содержит ли user_details еще 1 / users и так далее. Какой уровень нормализации лучше всего подходит для ваших нужд, зависит от ваших требований.

Если у вас есть одна таблица с хорошим индексом, это, вероятно, будет быстрее. Но с другой стороны, наверное, сложнее в обслуживании.

Мне кажется, что вы можете пропустить User_Details, поскольку это, вероятно, отношение 1 к 1 с пользователями. Но в остальном, вероятно, много строк на пользователя?