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

Так что это скорее вопрос дизайна.

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

Должен ли я иметь несколько таблиц, разбитых на категории в соответствии с информацией, или я должен иметь только одну таблицу с множеством столбцов?

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

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

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

Как это обычно делается?

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

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

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

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

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

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

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

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

people -> rel_p2staff -> staff

и

people -> rel_p2prosp -> prospects

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

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

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

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

Решением будет прямая связь между people -> staffиpeople -> prospect

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

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

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

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

Минусы: сложнее дизайн, запросы становятся немного сложнее

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

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

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

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