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

******* выделено отсюда Если 1С приделает еще и вменяемый блок бизнес-анализа (OLAP, легкая настройка пользователям) – остальным вендорам можно закрывать в СНГ деятельность по направлению учета. Они просто тут никому не нужны станут. ******

Цитата:

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

каменты к исходному блогу жгут
http://itblogs.ru/blogs/cio_anatomy/.../29/46495.aspx

обсуждение этого же блога
http://sql.ru/forum/actualthread.aspx?tid=651596

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

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

[mazzy]

Цитата:

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

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

А можно "позицию" переформулировать так, чтобы было понятно?

Цитата:

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

А можно "позицию" переформулировать так, чтобы было понятно?

давайте тогда сыграем в кто хочет стать миллионером
A) в конфигурациях 1С нет OLAP
B) в 1С не пониманиют, что такое OLAP
C) в конфигурациях 1С есть свой механизм, но он сложный и не работает как надо
D) в конфигурациях 1С есть компоновка данных, которая решает теже задачи, что и OLAP

т.е. начнем с легкого, не будем грузиться, а завяжеться дискусия, разовьем тему

to mazzy: нормально так?

Цитата:

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

А можно "позицию" переформулировать так, чтобы было понятно?

Может быть вынесем тогда мой вопрос в отдельную ветку?

[Sancho]

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

олап это совершенно боковой модуль, не зависящий ни от конфигураторов, ни от интерфейсов, ни от роли деятельности фирмы. следовательно, он подойдет ВСЕМ.
сколько внедрений по Москве? по Питеру? Ебургу? стране? сотни тысяч? допустим 100 000
это наши потенциальные клиенты. скольким он интересен? допустим, 30%-ам.
насколько я жадный? можно продавать олап по 1 000 рублей, 10 000 рублей, 50 000 рублей (думаю, потолок).
в зависимости от жадности модуль представляет интерес от 30 000 компаний до 2 000 компаний.

короче потенциал рынка - 3 - 100 каких-то жалких миллионов рублей.

зачем же стало дело?
думаю, найти толкового 1С-ника архитектора, ОЛАП-носителя технологий и пару разгильдяев-программистов не проблема.
через месяц появится уже что-то, что будет как-то работать.
через полгода и 5 внедрений появится комплексность решения
еще через полгода и 10 внедрений - велкам на рынок!

если после моего поста компаний 6 - 10 ринутся ваять свои олапы - круто! у вас еще и конкуренция появится! выживет сильнейший!

важно: если вы крутите-вертите кубики, жонглируете ими, но не можете результаты сунуть в Excel - модуль не будет популярным

[mazzy]

Цитата:

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

давайте тогда сыграем в кто хочет стать миллионером
A) в конфигурациях 1С нет OLAP
B) в 1С не пониманиют, что такое OLAP
C) в конфигурациях 1С есть свой механизм, но он сложный и не работает как надо
D) в конфигурациях 1С есть компоновка данных, которая решает теже задачи, что и OLAP

to mazzy: нормально так?

Нет. Я тупой. Не понимаю, что вы хотите сказать

Цитата:

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

т.е. начнем с легкого, не будем грузиться, а завяжеться дискусия, разовьем тему

Это называется троллинг.
http://ru.wikipedia.org/wiki/%D0%A2%...B8%D0%BD%D0%B3

Оно ЗДЕСЬ нужно? Вообще говоря, здесь не 1Совский форум.

Цитата:

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

Нет. Я тупой. Не понимаю, что вы хотите сказать



Это называется троллинг.
http://ru.wikipedia.org/wiki/%D0%A2%...B8%D0%BD%D0%B3

Оно ЗДЕСЬ нужно? Вообще говоря, здесь не 1Совский форум.

прошел по ссылке: "с целью вызвать флейм, конфликты между участниками, пустой трёп, оскорбления" -
нет цели пофлудить то как раз нет,
хочется понять, из тех, кто говорит что в 1С нет олапа, вообще в курсе темы, не важно будь то саперы, адепты аксапты или другой конкурирующей проги,
здесь народ вроде знает несколько систем, поэтому есть надежда на вразумительный диалог

>Нет. Я тупой
ну тогда я еще тупее
лучше скажи, что должен содержать текст, чтобы был "для тупых"

[brahma]

Цитата:

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

Оно ЗДЕСЬ нужно? Вообще говоря, здесь не 1Совский форум.

не, я просто офигеваю. Бурное обсуждение реализации OLAP в 1С (есть оно, нет его, как нет...), но как приходит человек разбирающийся, то сразу - "А оно ЗДЕСЬ нужно?"


А вот некоторые темы созданные Маззи
О размещении рекламы в продуктах "1С"
телеконференции "Антикризисные решения, практика, рекомендации от "1С" и KPMG"
Можно "пощупать" интерфейс 1С8.2 (управляемое приложение)
Изменения ассортимента, цен, условий поставки и сопровождения ряда продуктов «1С:Предприятия 7.7»
ВАЖНО - переход на продажу части ассортимента программ без НДС (по РФ) (как это делает 1С)

Так это, Маззи, а оно надо?

Цитата:

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

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

олап это совершенно боковой модуль, не зависящий ни от конфигураторов, ни от интерфейсов, ни от роли деятельности фирмы. следовательно, он подойдет ВСЕМ.
сколько внедрений по Москве? по Питеру? Ебургу? стране? сотни тысяч? допустим 100 000
это наши потенциальные клиенты. скольким он интересен? допустим, 30%-ам.
насколько я жадный? можно продавать олап по 1 000 рублей, 10 000 рублей, 50 000 рублей (думаю, потолок).
в зависимости от жадности модуль представляет интерес от 30 000 компаний до 2 000 компаний.

короче потенциал рынка - 3 - 100 каких-то жалких миллионов рублей.

зачем же стало дело?
думаю, найти толкового 1С-ника архитектора, ОЛАП-носителя технологий и пару разгильдяев-программистов не проблема.
через месяц появится уже что-то, что будет как-то работать.
через полгода и 5 внедрений появится комплексность решения
еще через полгода и 10 внедрений - велкам на рынок!

если после моего поста компаний 6 - 10 ринутся ваять свои олапы - круто! у вас еще и конкуренция появится! выживет сильнейший!

важно: если вы крутите-вертите кубики, жонглируете ими, но не можете результаты сунуть в Excel - модуль не будет популярным

а какие задачи по вашему решает OLAP - что это такое личнов вашем понимание (не ссылка на википедию)?
я так уверен, что вашу позицию занимают большинство, кто не знает 1С и считает что в 1С нет механизма, аналога OLAP

[Bober]

Цитата:

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

...если после моего поста компаний 6 - 10 ринутся ваять свои олапы...

компании планируют разработку ПО совсем не после чтения постов на форумах

[Sancho]

Цитата:

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

а какие задачи по вашему решает OLAP - что это такое личнов вашем понимание (не ссылка на википедию)?

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

Цитата:

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

я так уверен, что вашу позицию занимают большинство, кто не знает 1С и считает что в 1С нет механизма, аналога OLAP

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

[Sancho]

вики (http://ru.wikipedia.org/wiki/OLAP):

OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчётов по продажам, маркетингу, в целях управления, т. н. data mining — добыча данных (способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей).

мне мое определение больше нравится

Цитата:

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

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

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

если честно, именно поэтому и попросил ЛИЧНОЕ определение, и ваше имхо действительно лучше
давайте я его подитожу:
хранить данные (в базе) в удобном для быстрого вывода в отчеты
дать возможность строить отчет в ПРОИЗВОЛЬНОЙ аналитике

если Вам кажеться, что я говорю что-то не то, поправьте

Теперь "моя отсебятина", различия в подходах начались тогда, когда 1С решили сделать акцент на "быстрой разработке и минимальных знаниях при этом". Если все остальные программисты один раз и на века проектируют, а потому у них остро встала проблема с получением отчетов в нужной аналитике. То у 1С как раз стало иногда ДЕШЕВЛЕ перепроектировать хранение данных, я уж молчу о том, что легко поправить отчет.
Мои домыслы спорны, но хочу выделить, что с одной то истиной ни кто спорить не будет.
1) Для получения отчета мы можем хранить избыточные данные диске (цена объемов базы данных) и быстро делать по ним выборку в отчет, либо минимизировать объем базы только той информацией которая нужна для отчет и выполнять расчет "на лету" (цена времени построения).
2) 1С пошел по второму пути, но уже в 6-7ке оказалось, что не все так просто и появилась избыточность в виде "регистров", для которых платформа 1С:Предприятие строит дополнительные таблицы "итоги". Это еще не произвольная аналитика в смысле "любых" разрезов, но уже элементы OLAPа.
3) Но все равно на этом потребности пользователей в 1С не решались. Стали придумывать различные ухищерения. В 8ке появился универсальный инструментик "Характерстики", где программист уже больше не определяет полностью "что да как", а оставляет возможность ведения учета в произвольной аналитике пользователю. Да, количество характеристик ограничено и индексы неидеальные скажем так, но это движение к OLAPу.
4) Виртуальные таблицы. Нужно было работать с аналитикой времени, и платформу заполучила еще один механизм, ускоряющий работу, я бы его наверно не пореализации, но посути сравнил с вьюшками субд.
5) Компоновка данных. Вот это первый серьезный механизм, который занимается вопросом ПРОИЗВОЛЬНОЙ АНАЛИТИКИ. Тут ситуацию не простая прежде всего потому, что многие программисты 1С-ки уже привыкли к своему мышлению в кодировании и проектировании. Мне иногда кондрашка хватает, когда вижу в типовых попытку строить отчеты через "универсальный код" Поэтому новые отчет в компоновке данных существенно изменят черз год-два отношение пользователей, когда этот механизм начнет полноценно применяться пользователями, но призойдет это только ПОСЛЕ СМЕНЫ МЫШЛЕНИЯ программистами.

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

[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С!
Жаль! Концепция СКД - мне понравилась!

[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 для бедных".

[Raven Melancholic]

Цитата:

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

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

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

[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'е.

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

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