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

Question

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

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

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

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

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

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

Какой обычный способ сделать это?

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

people -> rel_p2staff -> staff

и

people -> rel_p2prosp -> prospects

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

Этот вид дизайна распространяется на всю базу данных.

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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