Более 100 столов

Question

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

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

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

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

Приветствия

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

Нет способа лучше организовать таблицы? Например, таблицы «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.)

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