100+ tables JOIN

Question

Мне было интересно, изменился ли кто-нибудь когда-либо, чтобы измерить, как будет выполняться 100 соединенных столов? Каждая таблица имеет столбец идентификатора с основным индексом, а вся таблица - 1: 1.

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

Таким образом, возможно, более реальным вопросом было бы то, как 30 таблиц (по 30 столбцов каждый) будут вести себя с многопользовательским соединением.

Строки 500K-1M должны быть ожидаемыми размерами таблиц.

Приветствия

Answer 1

Как правило, больше, чем 25 объединений могут быть проблемы с производительностью. Я пытаюсь сохранить соединения ниже 10-15. Это зависит от активности базы данных и количества одновременных пользователей, а также от отношения чтения/записи.

Предложите вам взглянуть на индексированные виды.

С любой хорошо настроенной базой данных «хорошие» индексы для рабочей нагрузки запроса являются ключом.

Answer 2

Они, скорее всего, будут работать ужасно, если у вас не было очень малого количества строк в таблице.

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

Answer 3

Нет способа лучше организовать таблицы? Например, таблица «DataPointTypes» и «DataPointValues»?

Например, если все ваши таблицы похожи на «WebsiteDataPoints (WebsitePage, Day, Visits)», «StoreDataPoints (Branch, Week, Sales)» и т. Д., Вы можете вместо этого использовать

DataPointSources(Name) 
(with data: Website,Store) 

DataPointTypes(SourceId, ColumnName) 
(with data: (Website, WebsitePage), (Website, Day), (Store, Branch), (Store, Sales) etc.) 

DataPointEntry(Id, Timestamp) 

DataPointValues (EntryId, Value(as varchar probably)) 
(with data: (1, Website-WebsitePage, 'pages.php'), (2, Store-Branch, 'MainStore'), (1, Website-Day, '12/03/1980'), (2, Store-Sales '35') etc.) 

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

Answer 4

То, что вы описали, похоже на реализацию column-oriented database (wikipedia). Данные хранятся в формате «основной столбец», который замедляет добавление каждой строки, но намного быстрее для запросов в случае предложения where, которое ограничивает возвращаемый набор строк.

Почему вы предпочитаете разделять строки? Это значит, что вы измеряете элементы данных для каждой строки в разное время? Или дело в том, что результат запроса в строке будет очень большим?

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

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

Если производительность не является проблемой, а не использует SQL JOINs, она может служить вам для явного списка столбцов, которые вы хотите получить в каждом запросе.Например, если вы хотите только получить ширину, высоту и длину для строки, вы можете использовать: SELECT width, height, length FROM datatable;, а не SELECT * FROM datatable; и добиться того же улучшения, что и получение меньшего количества возвращаемых данных. Используемые операторы SQL, вероятно, были бы короче, чем альтернативные заявления о соединении, которые мы рассматривали.