Доброго дня.
Занимаюсь нормализацией консолидирующей базы, которая собирает в себя данные еще с ~30 баз.
Вопрос: каким образом лучше выстроить серию запросов, чтобы во время консолидации данных скорость работы была максимальной быстрой, а масшабирование удобным?
Возникли следующие мысли:
1. Собирать юнионом данные из локальных таблиц; (медленно + последующие запросы будут обновлять изначальный юнион)
2. Создать серию запросов на добавления свежих данных в промежуточную таблицу в консолидирующей базе;
3. Создать в консолидирующей базе залинкованные с локальными базами таблицы из которых в последующем строить юнион.

Кратко: нужно собрать данные в единой структуре из 30 баз в одну максимально быстро, удобно и чтобы это еще и было гибко для масштабирования.

Подскажите, люди добрые, как же лучше сделать.

спасибо.

Akina,

в сети с доступом от другого хоста.

нужно свалить все в кучу и обрабатывать, второй вариант невозможен, т.к. администратор всей это "структуры" один, либо ему потребуется 1 раз сделать все, либо повторить одно и тоже 30 раз.

Akinakn9kaвторой вариант невозможен, т.к. администратор всей это "структуры" одинНи разу не обоснование.

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

Минус: данные могут быть неактуальными, т.е. с момента последнего копирования данных они могли измениться.

Минус: значительный объём консолидированной БД (а лимит на размер файла БД весьма невелик).

Плюс: обработка происходит локально.

Плюс: обработка не будет "затыкаться" в случае недоступности одного или нескольких удалённых хостов - при этом можно будет использовать последнюю версию полученных данных.

Мы ведь ведем речь об Access 2010?
Думал об этом варианте, но мне ненравится перспектива запуска процедуры, каждый раз когда нужно внести изменения, даже незначительные.

Akina,

Разницы нет, Вы правы, но есть альтернативы, как минимум в ввиде 30 юнионов. В этом варианте, всегда будут свежие данные.
Вопрос в том, что будет выполняться быстрее: процедура с приблудами или 30 юнионов.

то что в дальнейшем работать с процедурой будет быстрее - очевидно.

Akina,

Если я не путаю, процедуру нельзя использовать в качестве источника данных для того же селект (или я не прав?).
Если прав, то получается, чтобы получать онтайм данные, нужно будет нажимать процедуру, каждый раз когда данные обновяться.
Каждое обновление, даже с учетом приблуд в виде получения только свежих данных и прочего, будет сначала выгружать всю таблицу из локальной БД (а их 30), в последствии ограничивая выборку и запихивая их в промежуточную таблицу. Это ведь равносильно 30 юнионам в одном запросе, который в последствии можно использовать исходником для следующей серии запросов..

Akina,

да, я понял именно так, как Вы описали.
Мне кажется, что время работы процедуры = времени работы 30 юнионов. При учете, что данные нужно "вытягивать" из консолидированной базы довольно часто, создание процедуры просто добавляет еще 1 шаг для актуализации данных в момент необходимости.

пример:
30 юнионов: зашел в эксель - нажал обновить - он записал запрос, который джоинит справочники + 30 юнионов с базы. Подождал, получил данные.
процедура: зашел в эксель - нажал обновить - работаешь. Забыл, что нужно с локальных баз данные подятнуть - зашел в базу - нажал процедуру, ждешь. заходишь в эксель - жмешь обновить - работаешь.

Akina,

неисключено.
хотя наверное, если подумать, количество этих "исправлений" в локальных (частных) БД нестоль высоко, чтобы создавать запрос для обновления онтайм данных.

Akina,

рад что вы разделяете моё негодование.
Компания большая, много бюрократии и политики. Уже начали что-то придумывать, толкать идею, но когда время дойдет до реального появления СУБД неизвестно. Может полгода, может год, а может и больше.