FixinThe Dim!Для сбора данных... ну наприме .mdb файл или SQL Express, .
У 1С очень хорошие инструменты для построения отчетности (СКД например).
А для чего тут разляпистое СКД?

FixinПоэтому использовать MDB для накопления данных не есть гут...
У нас SQL-версия 1С в центре, соответственно и базу по управлению базами можно разместить в 1С-SQL формате. Будет летать намного шустрее MDB и не нужно думать насчет интеграции, протоколов обмена. Все родное, нативное и, тем не менее, быстрое.
Каков объм хранимых данныех - да крохи. Поэтому формат особо значения не имеет. Хоть в .csv. Хоть свой формат в том же .txt

Я о другом.
Кто будет собирать данные с удаленных баз(какой механизм-то)? Я предлогал орагнизовать некоторого "клиента" который бы и занимался этим. Тоесть, если есть n-серверов то каждый отчитается за свои базы и сбросит куда-то в "центр" данные - в каком виде?
В принцепе, можно же потом эти данные импортировать в каку-то конфигурацию и пользуй свое СКД сколько хочеш, можно сразу через OLE закидывать...
Я не вижу смысла тянуть все это в конфигураци. Т.к. информация весьма разнородная. Да и пока нету даже модели - исходя из чего писать?

Как вариант, можно заняться чем-то типа собирания и объединения разных открытых инструментов - на основе внешних отчетов, на основе виндовых скриптов. Создание чего-то вроде стандартной библиотеки/репозитария. С описанием, со стандартным вызововом... А по мере того как сложится какой-то костяк системы тогда уже думать о конфигурации.

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

Да, можно для этого использовать внешние обработки. Но это не то, потому как с помощью обработки ты не внесеш изменения в структуру базы. Например, где будет хранится статистические данные, в каких разрезах... ? Очевидно что это справочники и регистры, но какие, какова их структура... Если описывать это просто руками - типа прочти и внеси сам - муторно это. Опять же, как поддерживать эти плагины? Я назвал объект так, а ты эдак, версионность...

FixinЕще вот подумал, что хочу из заданных баз получать общее расписание регламентных обработок....

Вот потому-то и говорю, что у каждого свои требования к функционалу и одной конфигурацие это не покрыть. Или она будет разляписта как УПП. Опять же кто её будет подерживать, развивать.
А система с плагинами - не обязательно на платформе 1С - это севсем другой разговор. Достаточно организовать ядро системы, а там - если проект окажется интересным - народ сам будет дописывать/допиливать новые плагины - на свой вкус.

На чем если не на 1С?
Интерфейс: .hta, есть тот же Python...
Отчеты: ...HTML, Open/Microsoft офис...

FixinУ нас SQL-версия 1С в центре, соответственно и базу по управлению базами можно разместить в 1С-SQL формате. Будет летать намного шустрее MDB и не нужно думать насчет интеграции, протоколов обмена. Все родное, нативное и, тем не менее, быстрое.

Это кто кому родней доводится - 1C и MS SQL ?????
Скорость... - просто так сказать что SQL быстрее файловых баз(например Access) это невежество. Так как есть много "Если" и "Но". Почитай сравнения и тесты - обрати внимание на объем данных.