Ситуация следующая:
Из корпоративного приложения (C++) ежедневно выгружаются 3 DBF файла - 2 справочника и таблица с факт.оборотами за 1 день
Протянул связь от этих файлов в Access
Сделал под факт.обороты 2 абсолютно идентичные статичные таблицы с одинаковыми полями для оптимизации - в первой хранится история до 2009 года, во второй - текущий год, т.к. 99% всех SQL запросов по текущему году. Проиндексировал эти две таблицы по всем полям, которые связываются в SQL со связанными справочниками DBF.
В результате - таблица с Историей это 5 миллионов записей, таблица с текущим годом - 1,3 миллонов записей. Связанные справочники DBF - по 1000 записей в каждом.
Физически таблицы со справочниками естественно не связаны.
Справочники естественно не индексируются.
Новые записи добавляются в 2009 год из ежедневных DBF Insert-ом.
DBF-ники связанных справочников просто подменяются.
Вопрос 1: есть ли смысл в индексации, если в запросах индексированные таблицы обязательно Inner Join с DBF связками?
Вопрос 2: стоит ли для повышения производительности SQL сделать статичными в базе справочники DBF с их индексацией, Pkey & Fkey без DELETE Cascade т.к. статичные справочники придется ежедневно Delete & Insert (+предварительный разрыв связей и последующее создание связей)  из DBF с их последующей переиндексацией?
Вопрос 3: Есть 2-я база как клиент связанная с данным хранилищем- повлияет ли индексация здесь на производительность SQL там?
Как вообще лучше поступить, или у меня сейчас все оптимально? (sql запросы не обсуждаются - только структура базы)



Это сообщение отредактировал(а) FINANSIST - 8.10.2009, 11:14

Любые манипуляции со связанными DBF - это страдание одним нехорошим делом.
Если ты реально печёшься о быстродействии, следует импортировать данные из DBF в Аксессовскую таблицу нужной структуры с нужными индексами. А при старте БД (ну и ручной режим предусмотреть) сверять дату/время DBF с датой/временем последнего импорта, и если DBF более свежие - выполнять импорт.

FINANSIST, я думаю, что 
- самую лучшую производительность даст какой-нибудь полноценный SQL сервер. 
- имеет смысл перенести справочник из dbf в MS Access, т.к. уменьшится цепочка драйверов, которые участвуют в обработке драйверов.
- при любом объединени таблиц используется или строится индексация! Когда счет на миллионы, то индексы единственный способ повысить производительность объединения таблиц.
- MS Access использует концепцию файловой бд при доступе к данным. 
   Что это значит: Допустим бд лежит на комп1, клиентская бд на комп2. Когда клиентская бд доступается до таблицы, то вся таблица загружается на комп2. Т.е. если выполняется запрос с несколькими таблицами, то все таблицы целиком загружаются на комп2. Впечатляет? Так что в твоей ситуации все индексы не помогут ускорить работу пользователей по сети.

Резюмирую:
- завести SQL сервер
- в клиентской бд использовать ODBC запросы к серверу, без СВЯЗАННЫХ таблиц.
Если заинтересуетесь, могу поделиться опытом и небольшой библиотекой для создания подключения и прочих радостей. Я использовал mySQL.

Будет просто летать. Единственная сложность - изменять данные тяжеловато - придется программно писать инсерты и апдейты. Но для анализа это вообще может не пригодиться.

Добавлено через 1 минуту и 12 секунд

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

Я тебя правильно понял???


Не, у меня все проще: и хранилище и клиент висят на моем железе и в локаль не лезут - клиента создал из-за того, что есть регламентированная ежемесячная отчетность (15 довольно сложных отчетов) со своими процессами обработки данных хранилища, формами, процедурами  и личными локальными справочниками.
А в хранилище помимо данных только ежедневные разовые временные запросы для формирования кубов различным пользователям. Потому и спрашиваю: индексы хранилища ускорят работу клиента, если все протекает в рамках моего железа?



А вот на эту тему с тобой плотно пообщаюсь (правда не в рамках этого топика), т.к. планирую переводить всё это хозяйство либо на мускул, либо на жарптицу в которых опыта 0

Наполовину.
Такой процесс неминуемо вызовет рассогласование, и другие клиенты вместо данных получат цену на рис в Китае... оно тебе надо?
Следует создать в БД хранимую процедуру, которая выполнит необходимые действия (объявит транзакцию, заблокирует таблицы, уберёт индексы и констрейны, импортирует данные во временные таблицы, дропнет данные в постоянных таблицах, выполнит копирование новых данных, создаст индексы и констрейны и, если не было ошибок, закомиттит всё это дело).
Но это всё однозначно ADO, Jet или DAO не стреляют.

Уже наступил на эти грабли, еще голова не остыла
Но я уже упоминал, что клиент только у меня, хранилище тоже у меня и закрыть клиента мне ничего не стоит - но данная проблема возникает на другом этапе: слепил форму, в которой две подчиненной на основе запроса из аппендикса DBF в одной подчиненной и запрос из факт.оборотов тек.года в другой. Это необходимо для сравнения записей перед импортом во избежание дубликации ( группировка по датам - 30 записей это максимум) а так же для сравнения между тем что выгрузилось в DBF и тем что выгрузилось из C++ творения (косяки бывают).
Как ты и писал, ругается 

Есть конкретный код или решение на временную отвязку запросов форм от таблиц в процессе обработки? (RowSource?)





Это сообщение отредактировал(а) FINANSIST - 8.10.2009, 14:03

Таблица "REALIZ" - это DBF?
Сделай её импорт. Пуст источник данных будет родная, а не связанная, таблица.

Не, она как раз родная туда из DBF ежедневно вносятся "аппендиксы", думаю на нее функция ругается, так как контрол внедренный0 на форме, с которой запускаю функцию имеет следующий источник:

Как бы мне эту подчиненную форму от таблицы отключить в момент исполнения?

А это уже изврат. 

Может не стоит усложнять? Все обновления бд стоит делать при запуске приложения, если нужно. или по желанию пользователя, тогда все формы и отчеты закрыть и обновить.


DAO вполне потдреживает транзакции, если работать только в рамках MS Access.

При чём тут транзакции? Я о том, что только через ADO можно в Аксессовой базе создавать хранимки, триггеры и прочие вкусные вещи, из интерфейса недоступные.

Вот те раз, первый раз слышу!

В принципе да, но учитывая, что у меня в момент подгрузки висит только 1 форма, проще временно отключить контролы (тем более критичных контролов всего 2): решил проблему преобразовав подчиненнные формы в листбоксы с переключением rowsourcetype с Table/Query в Value list и обратно по завершению.
А что, Access не поддерживает временное отключение источников подчиненных форм?
И по индексам хранилища я так и не понял - они окажут положительное воздействие на скорость запросов в клиенте, или я зря парился с локализацией таблиц?


Это сообщение отредактировал(а) FINANSIST - 9.10.2009, 08:50

Окажут.


Все равно изврат. Это даст о себе знать, при развитии приложения.


Библиотека ADO.NET подреживает. Библиотеки DAO и ADO нет.

Это сообщение отредактировал(а) bopoha - 9.10.2009, 12:21