OLAP и 1С: У 1С прежде всего похожий по задачам инструмент - компоновщик. (C) Demiurg

[mazzy]

Разделил тему.

Цитата:

Сообщение от Demiurg

Мои домыслы спорны, но хочу выделить, что с одной то истиной ни кто спорить не будет.

с одной или со всеми пятью?

Цитата:

Сообщение от Demiurg

1) Для получения отчета мы можем хранить избыточные данные диске (цена объемов базы данных) и быстро делать по ним выборку в отчет, либо минимизировать объем базы только той информацией которая нужна для отчет и выполнять расчет "на лету" (цена времени построения).

Да.

Стоит добавить: обслуживание (пересчет) избыточных записей сильно замедляет операции вставки, обновления и удаления.

Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct).

Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством.
Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось.

Цитата:

Сообщение от Demiurg

2) 1С пошел по второму пути, но уже в 6-7ке оказалось, что не все так просто и появилась избыточность в виде "регистров", для которых платформа 1С:Предприятие строит дополнительные таблицы "итоги". Это еще не произвольная аналитика в смысле "любых" разрезов, но уже элементы OLAPа.

2.1. избыточность была раньше. Еще в 5.0 была, которая была до 2.0 Проф
2.2. в olap'е тоже разрезы не произвольны.

==============================

Цитата:

Сообщение от Demiurg

По указанным ссылка сторонники "в 1С нет вменямого олапчика" слегка в кусты дали.
Может кто-то здесь может аргументировать эту позицию?

Со своей стороны замечу, что увлекаясь жонглированием слова OLAP не стоит забывать о задачах, которые он решает. У 1С прежде всего похожий по задачам инструмент - компоновщик.

По-прежнему непонятно, к чему это обсуждение.

Цитата:

Сообщение от mazzy

Разделил тему.


с одной или со всеми пятью?.

Жирный текст.

Цитата:

Сообщение от mazzy

Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct).

Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством.
Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось.

Проблема в том, что пытаешься оценить 1С по аксапте. В 1с нет деления на OLTP и OLAP!!!

Это непривычно, может покаться неправильным, ну извиняйте, так получилось что селекты перемешаны с операциями вставки/обновления/удаления.
Однако отсюда делать вывод о правильности/неправильности подхода очень опасно.

Поэтому и пытаюсь понять лучше позицию ms-специалистов, и в тоже время проинформировать как 1с-специалист.

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

[ibc]

Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды!
Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С!
Жаль! Концепция СКД - мне понравилась!

[Raven Melancholic]

Цитата:

Сообщение от ibc

Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С!
Жаль! Концепция СКД - мне понравилась!

Так именно это и пытаются объяснить Demiurgу. Компоновка данных внешне конечно похожа на OLAP инструменты, но данные-то она собирает в момент формирования отчета, а не хранит в кубике предварительно рассчитанном. Поэтому говорить, что компоновка данных выполняет те же функции, что ОЛАП некорректно. Вряд ли какой аналитик будет ждать формирования отчета больше определенного времени.
А есть по теме, то в 1С есть регистры, которые в свое время Галимов называл "ОЛАП для бедных"

Цитата:

Сообщение от Raven Melancholic

Так именно это и пытаются объяснить Demiurgу. Компоновка данных внешне конечно похожа на OLAP инструменты, но данные-то она собирает в момент формирования отчета, а не хранит в кубике предварительно рассчитанном.

Да, исходные данные ты говоришь верные.
Только вот выводы у тебя ))

Немножечко был отвлечен работой, продолжаем

Цитата:

Сообщение от ibc

Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды!
Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С!
Жаль! Концепция СКД - мне понравилась!

Умышленно начал с определения, вспоминаем: ускорение отчетов, произвольная аналитика.
Ну так вот, OLAP вовсе не такой уж и "произвольный" всмысле всевозможных отчетов.
ВНИМАНИЕ! Утверждаю, что компоновщик позволяет строить больше различных разрезов и комбинаций!
Но цена тут же и вылазит, поскольку данные строятся "на лету", а не извлекаются с диска, скорость ниже, т.е. первая задача олапа не выполняется!!!

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

[Aleck]

Цитата:

Сообщение от Demiurg

Жирный текст.
Проблема в том, что пытаешься оценить 1С по аксапте. В 1с нет деления на OLTP и OLAP!!!

При чем тут Аксапта то?
OLAP, OLTP - это типы СУБД =)
Речь была о том, Imho,что в 1С такая запутанная и непрозрачная структура данных, что Olap прикручивать к ней очень тяжело...

[Сисой]

Я бы не сказал, что структура данных очень запутанная.
Сама идеология реализации прикладных объектов 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 для бедных".

[mazzy]

Цитата:

Сообщение от Сисой

Я бы не сказал, что структура данных очень запутанная.
Сама идеология реализации прикладных объектов 1С на таблицах СУБД довольно логична.

Хм... Попробую поработать толмачом: когда не1Сники говорят про "запутанность структуры", то скорее всего имеют в виду три вещи:
1) для "расшифровки" некоторых внутренних кодов нужно обращаться к самой конфигурации. а конфа хранится в виде blob'ов...
2) работа с иерархией справочников... сильно затрудняет работу с нормальными OLAP-системами
3) повсеместное использование искусственных ключей, а следовательно многоэтажные Join'ы сильно затрудняют reverse engeneering (разбирательство со структурой)

ну и сама структура... она в значительной мере унаследована. Для тех, кто пошел вместе с 1С всю историю она может быть и нормальная. Но для тех, кто работал с базами данных и с другими системами - она действительно "запутанная"

Цитата:

Сообщение от Сисой

И осваивается на раз-два (в отличие от пресловутой таблицы 1sconst.dbf в 1С 7.7)

Просто ты давно знаешь 1С и знаешь чего от нее стоит ждать, а чего не стоит

Цитата:

Сообщение от Сисой

1. Автогенерация платформой имен таблиц, индексов и реквизитов. Но, поскольку существует метод, возвращающий структуру физического представления объекта по его логическому имени, всегда можно создать по нему описания в OLAP-системе или view в СУБД.
2. Порой неоптимальные составные индексы таблиц, тормозящие SQL-сервер. Тут что-то сделать сложно, но если перегружать данные в OLAP, можно эту проблему игнорировать.

Это как раз и не сильно смущает. Хотя разработчики 1С могли бы выбрать и другую реализацию.

Цитата:

Сообщение от Сисой

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

Что ж ты так с темы на тему перескакиваешь лихо
Смотри:
1. Платформа ... обеспечивает
2. Механизм отчетов ... для пользователя
3. Язык запросов ... [для программиста]
4. Конструктор запросов ... [для кого?]

Утверждения имеют разный субьект.
В третьем утверждении субьект пропущен, но еще восстанавливается логически
В четвертом утверждении субьект пропущен. И его не восстановить логически

Цитата:

Сообщение от Сисой

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

Т.е. ты считаешь, что на мелких и на 90% крупных внедрений, интерфейс с OLAP не нужен. Правильно?

Можешь объяснить: почему?

Пока в основном идут чисто технологические моменты. Но они напомниают о басне, в которой "зелен виноград".
И всего-лишь один "Механизм отчетов удобен для подготовленного пользователя". Можешь пояснить этот момент? А лучше со скриншотами какого-нибудь OLAP-клиента и соответствующими возможностями ДЛЯ ПОЛЬЗОВАТЕЛЯ в 1С. А еще лучше со скриншотами функциональности ДЛЯ ПОЛЬЗОВАТЕЛЯ 1С, которой нет в стандартном OLAP'е.

=============
ЗЫ: только пожалуйста, функциональность ДЛЯ ПОЛЬЗОВАТЕЛЕЙ - что увидят пользователи, что смогут сделать пользователи, что смогут настроить сами пользователи и т.п.

Если хочешь, то можно добавить и функционал и для программистов. Но оценивать в первую очередь работу системы будут пользователи, а не программисты.

[Сисой]

Ой, как много вопросов.
Попробую ответить mazzy.
Незачем постоянно обращаться к структуре метаданных. В 1С8 даже перечисления на самом деле хранятся в таблицах СУБД. Какие ссылки ("внутренние коды") ты имел в виду?
А кто сказал, что иерархию справочников 1С нужно тащить в OLAP любой ценой? Я на своих проектах этим не заморачиваюсь, в крайнем случае модифицирую базу 1С, денормализируя таблицы под OLAP (например, добавляю поле РодительВерхнегоУровня (супердедушка? :-))).
Ты прав, нужно разделять функции для просто пользователей, опытных пользователей и программистов. По пятибалльной шкале в области быстрого построения отчетов и организации доступа к данным я бы оценил связку платформа+типовые конфигурации 1С8 для просто пользователей - на 3, для опытных пользователей - на 4, для программистов - 4- или 3+.

В целом возможности построителя отчетов 1С очень сильно напоминают продукты типа Oracle Discoverer. Однако ничего похожего на Oracle Express Server платформа 1С не предоставляет и имеющиеся возможности СУБД, на которых работает, не использует.
Зато, как ни странно, в составе платформы есть пародия на Oracle Darwin Data Mining Suite.

Думаю, что ограниченность использования OLAP-технологий фирмой 1С не в последнюю очередь связана с мультиСУБДшной реализацией. Это издержки.

[mazzy]

Цитата:

Сообщение от Сисой

Незачем постоянно обращаться к структуре метаданных. В 1С8 даже перечисления на самом деле хранятся в таблицах СУБД. Какие ссылки ("внутренние коды") ты имел в виду?

Например, Перечисления.

Цитата:

Сообщение от Сисой

А кто сказал, что иерархию справочников 1С нужно тащить в OLAP любой ценой?

Пока никто не говорил. Мало того, даже не предполагал такого поворота событий.
Но если в 1С и в ОЛАП будут разные представления справочников, то как к этому отнесутся ПОЛЬЗОВАТЕЛИ? ведь они же ожидают свои любимые справочники, а также получить итоги по группам

Не, это лучше вы, 1Сники, нам объясните: как вы пользователям даете разные представления?
И какой ценой достигается одинаковое представление?

Цитата:

Сообщение от Сисой

Ты прав, нужно разделять функции для просто пользователей, опытных пользователей и программистов. По пятибалльной шкале в области быстрого построения отчетов и организации доступа к данным я бы оценил связку платформа+типовые конфигурации 1С8 для просто пользователей - на 3, для опытных пользователей - на 4, для программистов - 4- или 3+.

а скриншоты? или хотя бы ссылки на http://v8.1c.ru ?
Мне, в общем то, и не надо. Но нас читают и другие участники.

Цитата:

Сообщение от Сисой

В целом возможности построителя отчетов 1С очень сильно напоминают продукты типа Oracle Discoverer. Однако ничего похожего на Oracle Express Server платформа 1С не предоставляет и имеющиеся возможности СУБД, на которых работает, не использует.
Зато, как ни странно, в составе платформы есть пародия на Oracle Darwin Data Mining Suite.

Скриншоты бы.

Часть выделена в отдельную ветку ограниченность ... 1С не в последнюю очередь связана с мультиСУБДшной реализацией

[ibc]

Цитата:

Сообщение от Сисой

По пятибалльной шкале в области быстрого построения отчетов и организации доступа к данным я бы оценил связку платформа+типовые конфигурации 1С8 для просто пользователей - на 3, для опытных пользователей - на 4, для программистов - 4- или 3+.

Оценка относительная или абсолютная? Если относительная, то какая система на 5 баллов?

Цитата:

Сообщение от Сисой

В целом возможности построителя отчетов 1С очень сильно напоминают продукты типа Oracle Discoverer. Однако ничего похожего на Oracle Express Server платформа 1С не предоставляет и имеющиеся возможности СУБД, на которых работает, не использует.
Зато, как ни странно, в составе платформы есть пародия на Oracle Darwin Data Mining Suite.

Чем СКД в 1С напоминает Oracle Discoverer, или вы имели ввиду именно построитель отчетов, а не СКД?

Что за пародия на Oracle Darwin Data, не объекты ли Интеллектуального анализа данных?

Цитата:

Сообщение от mazzy

И всего-лишь один "Механизм отчетов удобен для подготовленного пользователя".

=============
ЗЫ: только пожалуйста, функциональность ДЛЯ ПОЛЬЗОВАТЕЛЕЙ - что увидят пользователи, что смогут сделать пользователи, что смогут настроить сами пользователи и т.п.

Если хочешь, то можно добавить и функционал и для программистов. Но оценивать в первую очередь работу системы будут пользователи, а не программисты.

Солидарен, у разработчиков мало времени уходит на юзабилити. Но удобство очень плохо измеряется деньгами.
Кто хочет пофлудить на эту тему, ради бога. Но флуд тоже не оплачивается

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

И наконец, давайте поговорим о производительности 1С. Это в общем то моя специализация. Готов ответить думаю на все правильно сформулированные вопросы.
Но очень прошу, прежде чем мы начнем обсуждать код конфигураций/платформы, посмотрите эту заметку http://www.gilev.ru/1c/upp/
Она родилась в силу того, что в УПП параметры по-умолчанию настроены так, что быстродействие задушено на корню. А куча "методистов 1С" в фирмах заказчика говорит на вопрос "вы сразу списываете партии, или допроводите документы потом?" примерно так "а какая разница"!!! Т.е. они не понимают, что если УПП используется только бухами в крупной компании и партии им даром не нужны, то они заставляют УПП работать на 90% функциональность, которой даже не воспользуются.

К чему это я. Попробую доказать, что OLAP в привычном понимании не 1С программистов не нужен