mysql слишком много столбцов?

Question

Я создаю стол с 30-50 столбцами. Есть около 200K этих строк. Рекомендуется ли хранить эти данные в отдельных таблицах? Существуют ли проблемы с производительностью, когда у вас есть много столбцов.

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

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

При необходимости я могу указать более подробную информацию. Заранее благодарю за любой общий совет.

Answer 1

Чтобы уточнить ответ RichardOD «s, вам обычно имеют три варианта при работе с подтипированием, и которые вы выбираете, зависит от того, что вам нужно делать с данными.

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

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

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

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

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

Answer 2

Я думаю, что проблема в том, что у вас есть model like this (в магазине все в одном столе). This approach, а также this approach - это две альтернативы, которые вы можете выбрать - я уверен, что у других будет еще несколько предложений.

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

Если вы искренне заинтересованы в различиях между тремя подходами, я бы рекомендовал купить книгу «Модели шаблонов Enterprise Application Architecture» Мартина Фаулера.

Что касается характеристик производительности, вы можете посмотреть на вопросы like this one и also this one.

Вы можете прочитать о vertical partitioning in MySql here.

Answer 3

Я бы определенно посмотрел на normalizing the table. Хотя я не уверен в преимуществах производительности, скорее всего, это будет полезно для хранения с большим количеством записей.

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

Answer 4

Да, используйте много столбцов, если это имеет смысл. Если вы не используете антипаттерн, например «field1, field2, field3» и т. Д., Тогда все в порядке.

Много NULL - это хорошо, они не очень сильно болят. Также 200k - это такое маленькое количество строк, что вряд ли вы увидите много проблем с производительностью. Я не знаю, сколько вложений вы планируете делать в этой таблице, но если это < 100 в секунду, я не вижу ничего, что может быть проблемой.

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

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

Answer 5

200K раз 50 значений не является огромным столом. Не беспокойтесь о производительности, пока у вас не будет таких вещей, как простота использования и свобода от самостоятельного противоречия под контролем.

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

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

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

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