13.04.2009, 14:37 | #11 |
Участник
|
Цитата:
1) для "расшифровки" некоторых внутренних кодов нужно обращаться к самой конфигурации. а конфа хранится в виде blob'ов... 2) работа с иерархией справочников... сильно затрудняет работу с нормальными OLAP-системами 3) повсеместное использование искусственных ключей, а следовательно многоэтажные Join'ы сильно затрудняют reverse engeneering (разбирательство со структурой) ну и сама структура... она в значительной мере унаследована. Для тех, кто пошел вместе с 1С всю историю она может быть и нормальная. Но для тех, кто работал с базами данных и с другими системами - она действительно "запутанная" Цитата:
Цитата:
Сообщение от Сисой
1. Автогенерация платформой имен таблиц, индексов и реквизитов. Но, поскольку существует метод, возвращающий структуру физического представления объекта по его логическому имени, всегда можно создать по нему описания в OLAP-системе или view в СУБД.
2. Порой неоптимальные составные индексы таблиц, тормозящие SQL-сервер. Тут что-то сделать сложно, но если перегружать данные в OLAP, можно эту проблему игнорировать. Цитата:
Сообщение от Сисой
В целом платформа 1С за счет использования механизма регистров обеспечивает вполне приемлемое время построения простых отчетов (разного рода своды и "шахматки"). Механизм отчетов удобен для подготовленного пользователя.
Язык запросов неплох, жаль лишь, что коррелированные подзапросы не поддерживаются. Конструктор запросов очень хорош. Смотри: 1. Платформа ... обеспечивает 2. Механизм отчетов ... для пользователя 3. Язык запросов ... [для программиста] 4. Конструктор запросов ... [для кого?] Утверждения имеют разный субьект. В третьем утверждении субьект пропущен, но еще восстанавливается логически В четвертом утверждении субьект пропущен. И его не восстановить логически Цитата:
Сообщение от Сисой
Мое мнение: интерфейс c OLAP 1С-у не помешал бы, но реально он нужен максимум на 10% крупных внедрений, в которых и кастомизации много и базы большие. А раз много кастомизировано, то и универсальной настройки не создать, только заготовку под типовые конфигурации. В остальных проектах возможности самой 1С вполне достаточно.
Можешь объяснить: почему? Пока в основном идут чисто технологические моменты. Но они напомниают о басне, в которой "зелен виноград". И всего-лишь один "Механизм отчетов удобен для подготовленного пользователя". Можешь пояснить этот момент? А лучше со скриншотами какого-нибудь OLAP-клиента и соответствующими возможностями ДЛЯ ПОЛЬЗОВАТЕЛЯ в 1С. А еще лучше со скриншотами функциональности ДЛЯ ПОЛЬЗОВАТЕЛЯ 1С, которой нет в стандартном OLAP'е. ============= ЗЫ: только пожалуйста, функциональность ДЛЯ ПОЛЬЗОВАТЕЛЕЙ - что увидят пользователи, что смогут сделать пользователи, что смогут настроить сами пользователи и т.п. Если хочешь, то можно добавить и функционал и для программистов. Но оценивать в первую очередь работу системы будут пользователи, а не программисты. |
|
Теги |
1c, olap, компоновщик, скд |
|
|