|
12.04.2009, 10:34 | #1 |
Гость
|
Цитата:
Сообщение от 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. |
|
12.04.2009, 10:52 | #2 |
Участник
|
Разделил тему.
Цитата:
Цитата:
Стоит добавить: обслуживание (пересчет) избыточных записей сильно замедляет операции вставки, обновления и удаления. Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct). Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством. Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось. Цитата:
Сообщение от Demiurg
2) 1С пошел по второму пути, но уже в 6-7ке оказалось, что не все так просто и появилась избыточность в виде "регистров", для которых платформа 1С:Предприятие строит дополнительные таблицы "итоги". Это еще не произвольная аналитика в смысле "любых" разрезов, но уже элементы OLAPа.
2.2. в olap'е тоже разрезы не произвольны. ============================== Цитата:
Сообщение от Demiurg
По указанным ссылка сторонники "в 1С нет вменямого олапчика" слегка в кусты дали.
Может кто-то здесь может аргументировать эту позицию? Со своей стороны замечу, что увлекаясь жонглированием слова OLAP не стоит забывать о задачах, которые он решает. У 1С прежде всего похожий по задачам инструмент - компоновщик. |
|
12.04.2009, 22:09 | #3 |
Гость
|
Жирный текст.
Цитата:
Сообщение от mazzy
Собственно разделяют OLTP и OLAP системы по критерию: какие операции являются приоритетными - обновление (insert/update/delete) или выборки данных (seelct). Поэтому утверждая "1С решил", "1С пошел" надо понимать, что это означает "1С выбрал замедление операций обновления, ускоряя операций выборки". Т.е. тормонутость 1С в многопользовательской среде является врожденным свойством. Я не думаю, что этот выбор был сознательным. Скорее всего, так получилось. Это непривычно, может покаться неправильным, ну извиняйте, так получилось что селекты перемешаны с операциями вставки/обновления/удаления. Однако отсюда делать вывод о правильности/неправильности подхода очень опасно. Поэтому и пытаюсь понять лучше позицию ms-специалистов, и в тоже время проинформировать как 1с-специалист. Поэтому когда поднял вопрос про OLAP, специально выделил две задачи: ускорение отчетов, произвольная аналитика (с некоторыми моментами, о которых скажу позже). Сейчас сделаю паузу, надеюсь аудитория тобой не исчерпана и будут еще мысли от коллег. |
|
13.04.2009, 13:01 | #4 |
Участник
|
Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды! Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С! Жаль! Концепция СКД - мне понравилась! |
|
13.04.2009, 14:12 | #5 |
Участник
|
Цитата:
А есть по теме, то в 1С есть регистры, которые в свое время Галимов называл "ОЛАП для бедных" |
|
13.04.2009, 22:33 | #6 |
Гость
|
Цитата:
Только вот выводы у тебя )) |
|
13.04.2009, 22:31 | #7 |
Гость
|
Немножечко был отвлечен работой, продолжаем
Цитата:
Сообщение от ibc
Компоновка данных - это встроенное средство для написания отчетности, в том числе с использованием сводной таблицы, так или иначе показать данные в виде N-мерного отчета!
Но это не OLAP! 1С работает медленно, и не может претендовать на обработку большого количества информации за 1-2 секунды! Даже если сделать отчет с СКД (сист. компан. данных) легче быстрее и нагляднее, чем в другой системе построения отчетности - все сходит на НЕТ быстродействие 1С! Жаль! Концепция СКД - мне понравилась! Ну так вот, OLAP вовсе не такой уж и "произвольный" всмысле всевозможных отчетов. ВНИМАНИЕ! Утверждаю, что компоновщик позволяет строить больше различных разрезов и комбинаций! Но цена тут же и вылазит, поскольку данные строятся "на лету", а не извлекаются с диска, скорость ниже, т.е. первая задача олапа не выполняется!!! Таким образом, компоновщик данных дает большую гибкость в смысле различных разрезов. Но тут есть много вопросов. Но пока хотелось бы услышать мнение спецов по аксапте - не вру ли я с ограничением по разрезам аналитики. И потом пойдем дальше. |
|
13.04.2009, 13:27 | #8 |
Участник
|
Цитата:
OLAP, OLTP - это типы СУБД =) Речь была о том, Imho,что в 1С такая запутанная и непрозрачная структура данных, что Olap прикручивать к ней очень тяжело... |
|
13.04.2009, 14:09 | #9 |
Участник
|
Я бы не сказал, что структура данных очень запутанная.
Сама идеология реализации прикладных объектов 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. |
|
13.04.2009, 14:37 | #10 |
Участник
|
Цитата:
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'е. ============= ЗЫ: только пожалуйста, функциональность ДЛЯ ПОЛЬЗОВАТЕЛЕЙ - что увидят пользователи, что смогут сделать пользователи, что смогут настроить сами пользователи и т.п. Если хочешь, то можно добавить и функционал и для программистов. Но оценивать в первую очередь работу системы будут пользователи, а не программисты. |
|
13.04.2009, 15:27 | #11 |
Участник
|
Ой, как много вопросов.
Попробую ответить 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С не в последнюю очередь связана с мультиСУБДшной реализацией. Это издержки. |
|
13.04.2009, 22:38 | #12 |
Гость
|
Цитата:
Сообщение от mazzy
И всего-лишь один "Механизм отчетов удобен для подготовленного пользователя".
============= ЗЫ: только пожалуйста, функциональность ДЛЯ ПОЛЬЗОВАТЕЛЕЙ - что увидят пользователи, что смогут сделать пользователи, что смогут настроить сами пользователи и т.п. Если хочешь, то можно добавить и функционал и для программистов. Но оценивать в первую очередь работу системы будут пользователи, а не программисты. Кто хочет пофлудить на эту тему, ради бога. Но флуд тоже не оплачивается Я думаю все заметили, что в Новых решениях сначала оттачивается функциональность, потом оптимизируется производительность, по факту структура хранения данных (преимущественно регистры накопления и бухгалтерии) и наконец конфигурации проходят состояние юзабилити-шлифовки. Последнюю стадию пока что успешно прошла имхо 1С:Бухгалтерия ))))) Последний раз редактировалось Demiurg; 13.04.2009 в 22:48. |
|
Теги |
1c, olap, компоновщик, скд |
|
|