Таблица MySQL с вертикальным разделением

Я рассматриваю случай, когда у меня более 200 столбцов, в основном varchar (100). Столбцы взяты из нескольких внешних источников данных, таких как данные CRM / демографии и т. д. Я не могу хранить их в одной таблице MySQL с постоянно растущим числом столбцов.

Общая ситуация запроса может содержать столбцы из одного или нескольких вертикальных разделов.

  • Разбить их по вертикали - хорошая идея? и присоединиться к ним по запросу?
  • Какого размера должен быть каждый раздел (количество столбцов)? Для повышения производительности.
  • Каким должно быть наилучшее условие соответствия JOIN?

Версия MySQL: 5.7 Механизм хранения: InnoDB

А как насчет горизонтального разделения?

Tim Biegeleisen 27.03.2018 08:51

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

Hassan Farid 27.03.2018 08:52

Хорошо, но таблицы обычно растут по вертикали, а не по горизонтали.

Tim Biegeleisen 27.03.2018 08:59

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

Sloan Thrasher 27.03.2018 09:01
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для разработчиков
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для разработчиков
В последние годы архитектура микросервисов приобрела популярность как способ построения масштабируемых и гибких приложений. Laravel , популярный PHP...
Как построить CRUD-приложение в Laravel
Как построить CRUD-приложение в Laravel
Laravel - это популярный PHP-фреймворк, который позволяет быстро и легко создавать веб-приложения. Одной из наиболее распространенных задач в...
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
В предыдущем посте мы создали функциональность вставки и чтения для нашей динамической СУБД. В этом посте мы собираемся реализовать функции обновления...
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
Роли и разрешения пользователей без пакета Laravel 9
Роли и разрешения пользователей без пакета Laravel 9
Этот пост изначально был опубликован на techsolutionstuff.com .
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
1
4
219
1

Ответы 1

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

  • Действительно ли несколько столбцов представляют собой «массив, растянутый по столбцам»? Например, "foo1", foo2 "," foo3 ", ...? Если так, то на самом деле должен не будет просто вертикально секционирован, а превращен в несколько строк в другой таблице.

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

  • Вы говорите «большинство из них - VARCHAR(100)». Сделайте разумные верхние границы; это поможет (некоторым) избежать ограничения размера строки.

  • Некоторые из столбцов "разреженные"? То есть в большинстве строк нет записей для этих значений? Затем соберите в одну колонку JSON. (Или пару столбцов JSON, если есть четкое разделение.) Если у вас есть старая версия MySQL / MariaDB (а у вас ее нет), просто поместите строку JSON в столбец TEXT.

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

Другие вопросы по теме