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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

people -> rel_p2staff -> staff 

и

people -> rel_p2prosp -> prospects 

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

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

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

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

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

Answer 7

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