MySQL: несколько таблиц или одна таблица со многими столбцами?

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

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

Я новичок в дизайне базы данных, поэтому какой подход лучше, а какие плюсы и минусы? Какой обычный способ сделать это?

Ответ 1

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

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

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

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

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

Ответ 2

Одна большая таблица часто является плохим выбором. Связанные таблицы - это то, с чем была разработана реляционная база данных. Если вы правильно индексируете и знаете, как писать исполняемые запросы, они будут работать нормально.

Когда таблицы получают слишком много столбцов, вы можете столкнуться с проблемами с фактическим размером страницы, на которой база данных хранит информацию. Либо запись может оказаться слишком большой для страницы, в которой вы можете не создавать или обновлять определенную запись, которая делает пользователей недовольными, или вы можете (в SQL Server по крайней мере) допускать переполнение для определенного datatypes (с набором правил, которые вам нужно найти, если вы это делаете), но если многие записи переполнят размер страницы, вы можете создавать сложные проблемы с производительностью. Теперь, как MYSQL обрабатывает страницы и есть ли у вас проблемы, когда размер потенциальной страницы становится слишком большим, вам нужно будет найти документацию для этой базы данных.

Ответ 3

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

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

Дизайн контуров сложнее, запросы становятся несколько более сложными

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

Ответ 4

У меня есть хороший пример. Слишком нормализованная база данных со следующим набором отношений:

people -> rel_p2staff -> staff

people -> rel_p2prosp -> prospects

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

Этот вид дизайна ведется для всей базы данных.

Теперь, чтобы запросить этот набор отношений, он объединяет несколько таблиц, иногда присоединяется 8 и более таблиц. Он работает отлично до середины этого года, когда он начал очень медленно, когда мы прошли 40000 записей людей.

В прошлом году индексирование и все низко висящие фрукты были израсходованы, все запросы оптимизированы до совершенства. Это конец пути для конкретного нормализованного проектирования и управления, теперь одобренный пересмотренный вариант всего приложения, который зависит от него, а также реструктуризация базы данных в течение 6 месяцев. $$$$ Ouch.

Решение будет иметь прямое отношение для people -> staff и people -> prospect

Ответ 5

Я уже сделал какой-то проект базы данных. для меня это зависит от сложности системы с управлением базой данных; да, правда, иметь уникальные данные только в одном месте, но очень сложно делать запросы с чрезмерно нормализованной базой данных с большим количеством записей. Просто соедините две схемы; используйте одну огромную таблицу, если вы чувствуете, что у вас будут массивные записи, которые трудно поддерживать, например, facebook, gmail и т.д. и использовать другую таблицу для одного набора записей для простой системы... ну это только мое мнение.. я надеюсь, что это может помочь.. просто сделайте это.. вы можете это сделать...:)

Ответ 6

Обычным способом сделать это будет использование разных таблиц, как в схеме звездочки, так и в схеме снежинок. Howeevr, я бы основывал эту стратегию на два раза. Я верю в теорию, что данные должны существовать только в одном месте, поскольку схема, о которой я упоминал, будет работать хорошо. Тем не менее, я также считаю, что для механизмов отчетности и наборов BI колоссальный подход был бы чрезвычайно полезен, потому что он больше поддерживает потребности в отчетности. Колонкарные подходы, подобные тем, у которых есть infobright.org, имеют огромную производительность и сжатие, что делает использование обоих подходов невероятно полезным. Многие компании начинают понимать, что только одна архитектура базы данных в организации не поддерживает весь спектр своих потребностей. Многие компании внедряют концепцию создания более чем одной архитектуры базы данных.

Ответ 7

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