Показать сообщение отдельно
Старый 13.04.2009, 14:09   #18  
Сисой is offline
Сисой
Участник
Аватар для Сисой
Злыдни
1C
 
938 / 339 (13) ++++++
Регистрация: 05.02.2003
Адрес: Москва
Я бы не сказал, что структура данных очень запутанная.
Сама идеология реализации прикладных объектов 1С на таблицах СУБД довольно логична.
И осваивается на раз-два (в отличие от пресловутой таблицы 1sconst.dbf в 1С 7.7)
Смущают две особенности:
1. Автогенерация платформой имен таблиц, индексов и реквизитов. Но, поскольку существует метод, возвращающий структуру физического представления объекта по его логическому имени, всегда можно создать по нему описания в OLAP-системе или view в СУБД.
2. Порой неоптимальные составные индексы таблиц, тормозящие SQL-сервер. Тут что-то сделать сложно, но если перегружать данные в OLAP, можно эту проблему игнорировать.

В целом платформа 1С за счет использования механизма регистров обеспечивает вполне приемлемое время построения простых отчетов (разного рода своды и "шахматки"). Механизм отчетов удобен для подготовленного пользователя.
Язык запросов неплох, жаль лишь, что коррелированные подзапросы не поддерживаются. Конструктор запросов очень хорош.
Сложности начинаются, когда нужно "на лету" производить расчеты и анализ данных - здесь интерпретатор 1С может стать "бутылочным горлышком".
Кроме того, многие конфигурации 8-ой платформы писались на версии 8.0, которая не умела создавать временные таблицы, из-за чего авторы запросов городили монструозные селекты страниц на 5 кода. Ясен пень, такие запросы притормаживают...

Мое мнение: интерфейс c OLAP 1С-у не помешал бы, но реально он нужен максимум на 10% крупных внедрений, в которых и кастомизации много и базы большие. А раз много кастомизировано, то и универсальной настройки не создать, только заготовку под типовые конфигурации.
В остальных проектах возможности самой 1С вполне достаточно. Как правильно заметит Raven Melancholic в следующем посте, спасает "OLAP для бедных".

Последний раз редактировалось Сисой; 13.04.2009 в 14:34.