|
![]() |
#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 - модуль не будет популярным ![]() я так уверен, что вашу позицию занимают большинство, кто не знает 1С и считает что в 1С нет механизма, аналога OLAP |
|
![]() |
#2 |
Administrator
|
Цитата:
он отличается от "отчета" тем, что данных очень много, но они уже собраны и проиндексированы. и там где отчет будет трудиться полчаса и выше, OLAP должен в самом простейшем виде (в виде таблицы) предоставить инфу за секунду -другую. это мое видение, не настаиваю. а теперь слазию в вики - сверюсь ![]() Цитата:
![]() если написал какую-то ерунду, простите. хотел всего лишь помочь 1Су развиваться успешней ![]() |
|
![]() |
#3 |
Гость
|
Цитата:
Сообщение от Sanch
![]() я бы сказал, что OLAP это инструмент индексированного сохранения больших объемов произвольных структурированных данных и инструмент, позволяющий в кратчайшие сроки (секунды) представить эти данные в агрегированном виде в любом срезе (аналитике), с любыми фильтрами. опять же в виде, удобном для последующего анализа.
он отличается от "отчета" тем, что данных очень много, но они уже собраны и проиндексированы. и там где отчет будет трудиться полчаса и выше, OLAP должен в самом простейшем виде (в виде таблицы) предоставить инфу за секунду -другую. это мое видение, не настаиваю. а теперь слазию в вики - сверюсь ![]() а откуда тогда темы с таким названием? я как прочел - сразу подумал, что именно отсутствие подобного механизма и тормозит внедреж. непорядок! ![]() если написал какую-то ерунду, простите. хотел всего лишь помочь 1Су развиваться успешней ![]() давайте я его подитожу: хранить данные (в базе) в удобном для быстрого вывода в отчеты дать возможность строить отчет в ПРОИЗВОЛЬНОЙ аналитике если Вам кажеться, что я говорю что-то не то, поправьте Теперь "моя отсебятина", различия в подходах начались тогда, когда 1С решили сделать акцент на "быстрой разработке и минимальных знаниях при этом". Если все остальные программисты один раз и на века проектируют, а потому у них остро встала проблема с получением отчетов в нужной аналитике. То у 1С как раз стало иногда ДЕШЕВЛЕ перепроектировать хранение данных, я уж молчу о том, что легко поправить отчет. Мои домыслы спорны, но хочу выделить, что с одной то истиной ни кто спорить не будет. 1) Для получения отчета мы можем хранить избыточные данные диске (цена объемов базы данных) и быстро делать по ним выборку в отчет, либо минимизировать объем базы только той информацией которая нужна для отчет и выполнять расчет "на лету" (цена времени построения). 2) 1С пошел по второму пути, но уже в 6-7ке оказалось, что не все так просто и появилась избыточность в виде "регистров", для которых платформа 1С:Предприятие строит дополнительные таблицы "итоги". Это еще не произвольная аналитика в смысле "любых" разрезов, но уже элементы OLAPа. 3) Но все равно на этом потребности пользователей в 1С не решались. Стали придумывать различные ухищерения. В 8ке появился универсальный инструментик "Характерстики", где программист уже больше не определяет полностью "что да как", а оставляет возможность ведения учета в произвольной аналитике пользователю. Да, количество характеристик ограничено и индексы неидеальные скажем так, но это движение к OLAPу. 4) Виртуальные таблицы. Нужно было работать с аналитикой времени, и платформу заполучила еще один механизм, ускоряющий работу, я бы его наверно не пореализации, но посути сравнил с вьюшками субд. 5) Компоновка данных. Вот это первый серьезный механизм, который занимается вопросом ПРОИЗВОЛЬНОЙ АНАЛИТИКИ. Тут ситуацию не простая прежде всего потому, что многие программисты 1С-ки уже привыкли к своему мышлению в кодировании и проектировании. Мне иногда кондрашка хватает, когда вижу в типовых попытку строить отчеты через "универсальный код" ![]() На этом пока остановлюсь. Чтобы "не отороваться от земли". Давайте обсудим расхождения в видении, того что написал, потом пойдем дальше, если будет желание. Последний раз редактировалось Demiurg; 12.04.2009 в 10:45. |
|
![]() |
#4 |
Участник
|
Разделил тему.
Цитата:
Цитата:
Стоит добавить: обслуживание (пересчет) избыточных записей сильно замедляет операции вставки, обновления и удаления. Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct). Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством. ![]() Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось. Цитата:
Сообщение от Demiurg
![]() 2) 1С пошел по второму пути, но уже в 6-7ке оказалось, что не все так просто и появилась избыточность в виде "регистров", для которых платформа 1С:Предприятие строит дополнительные таблицы "итоги". Это еще не произвольная аналитика в смысле "любых" разрезов, но уже элементы OLAPа.
2.2. в olap'е тоже разрезы не произвольны. ============================== Цитата:
Сообщение от Demiurg
![]() По указанным ссылка сторонники "в 1С нет вменямого олапчика" слегка в кусты дали.
Может кто-то здесь может аргументировать эту позицию? Со своей стороны замечу, что увлекаясь жонглированием слова OLAP не стоит забывать о задачах, которые он решает. У 1С прежде всего похожий по задачам инструмент - компоновщик. |
|
![]() |
#5 |
Гость
|
Жирный текст.
Цитата:
Сообщение от mazzy
![]() Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct). Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством. ![]() Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось. Это непривычно, может покаться неправильным, ну извиняйте, так получилось что селекты перемешаны с операциями вставки/обновления/удаления. Однако отсюда делать вывод о правильности/неправильности подхода очень опасно. Поэтому и пытаюсь понять лучше позицию ms-специалистов, и в тоже время проинформировать как 1с-специалист. Поэтому когда поднял вопрос про OLAP, специально выделил две задачи: ускорение отчетов, произвольная аналитика (с некоторыми моментами, о которых скажу позже). Сейчас сделаю паузу, надеюсь аудитория тобой не исчерпана и будут еще мысли от коллег. |
|
![]() |
#6 |
Участник
|
Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды! Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С! Жаль! Концепция СКД - мне понравилась! |
|
![]() |
#7 |
Участник
|
Цитата:
А есть по теме, то в 1С есть регистры, которые в свое время Галимов называл "ОЛАП для бедных" ![]() |
|
![]() |
#8 |
Гость
|
Немножечко был отвлечен работой, продолжаем
Цитата:
Сообщение от ibc
![]() Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды! Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С! Жаль! Концепция СКД - мне понравилась! Ну так вот, OLAP вовсе не такой уж и "произвольный" всмысле всевозможных отчетов. ВНИМАНИЕ! Утверждаю, что компоновщик позволяет строить больше различных разрезов и комбинаций! Но цена тут же и вылазит, поскольку данные строятся "на лету", а не извлекаются с диска, скорость ниже, т.е. первая задача олапа не выполняется!!! Таким образом, компоновщик данных дает большую гибкость в смысле различных разрезов. Но тут есть много вопросов. Но пока хотелось бы услышать мнение спецов по аксапте - не вру ли я с ограничением по разрезам аналитики. И потом пойдем дальше. |
|
![]() |
#9 |
Участник
|
Цитата:
OLAP, OLTP - это типы СУБД =) Речь была о том, Imho,что в 1С такая запутанная и непрозрачная структура данных, что Olap прикручивать к ней очень тяжело... |
|
![]() |
#10 |
Участник
|
Я бы не сказал, что структура данных очень запутанная.
Сама идеология реализации прикладных объектов 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. |
|
Теги |
1c, olap, компоновщик, скд |
|
|