Size: a a a

2021 February 19

SP

Sergey Polekhin in Qlik BI chat
Igor Burobin
Да, я не против хранилищ. Qlik решает не все задачи, но есть категория запросов которая по скорости просто не будет решатся хранилищами. Особенно с корпоративностью повышенной - пока ЗНИ (ЧТЗ, ТЗ, спеки) напишут, все согласуют и тп бизнесу уже будет все равно решена задача или нет
+1
источник

MC

Makha Cloud in Qlik BI chat
Тока на днях видел вакансию power bi (М, дакс, сиквел,пайтон)
источник

SP

Sergey Polekhin in Qlik BI chat
V N
Ну так в Qlik тоже в базе 2 языка: скрипт и Set Analysis и они разные...
И заметьте,  Set-анализ гораздо ближе и по читаемости и по восприятию для бизнес-пользователя, чем конструкции DAX. Хотя бы тем, что в нём не нужно писать названия таблиц и заниматься обрамлениями типа Calculate()
источник

SP

Sergey Polekhin in Qlik BI chat
Makha Cloud
Тока на днях видел вакансию power bi (М, дакс, сиквел,пайтон)
Точно. Но даже зная всё это, сложные задачи в итоге приходится решать в Qlik
источник

VN

V N in Qlik BI chat
Igor Burobin
да. У людей мания "мы сделаем ЕДИНОЕ хранилище для всего". забудьте сразу про это мой вам совет
А где в контексте было ЕДИНОЕ и для ВСЕГО?
Но ряд задач без этого решается гораздо сложнее...
Зачем же пытаться в крайности бросаться...
источник

MC

Makha Cloud in Qlik BI chat
Sergey Polekhin
Точно. Но даже зная всё это, сложные задачи в итоге приходится решать в Qlik
Ну есть alteryx 😉где не нужно кодить))
источник

VN

V N in Qlik BI chat
Sergey Polekhin
И заметьте,  Set-анализ гораздо ближе и по читаемости и по восприятию для бизнес-пользователя, чем конструкции DAX. Хотя бы тем, что в нём не нужно писать названия таблиц и заниматься обрамлениями типа Calculate()
Человеку который работал только с формулами Excel (и не силен в теории множеств) это будет не так очевидно...
источник

VN

V N in Qlik BI chat
Igor Burobin
Есть категория задач не для Qlik. Например среднедневные остатки считать не удобно. можно, но неудобно. проще в другом месте делать
Для относительно небольшого количества данных считается вполне сносно и на лету...
источник

IB

Igor Burobin in Qlik BI chat
Sergey Polekhin
Точнее, они могут быть оооочень большими и при этом их даже может быть не одно )))
Но я не видел ни одного заказчика удовлетвореного со стороны бизнеса своим хранилищем - в понимании бизнеса там всегда чего-то не хватает и всегда что-то вовремя не найти )))
Да, делают несколько. Сначала одно, потом OLAP так как обычная медленная, потом настает время аналитических БД так как и OLAP уже медленное; потом еще к ним может добавится еще open source шардированная система которая для бигдаты и разворачивается на 10 серверах. В итоге зоопарк из систем легаси и не очень. А пользователи в Excel ВПР делают из 2з таблиц 🤣🤣
источник

IB

Igor Burobin in Qlik BI chat
V N
Для относительно небольшого количества данных считается вполне сносно и на лету...
Да, сейчас сервера подросли 😊
источник

IB

Igor Burobin in Qlik BI chat
Раньше 50 000 товаров 365 дней 5 лет тяжеловато было. Но для Qlik еще проблема будет на каждый день остаток посчитать по движению чисто алгоритмически - тупо долго
источник

VN

V N in Qlik BI chat
Igor Burobin
Да, делают несколько. Сначала одно, потом OLAP так как обычная медленная, потом настает время аналитических БД так как и OLAP уже медленное; потом еще к ним может добавится еще open source шардированная система которая для бигдаты и разворачивается на 10 серверах. В итоге зоопарк из систем легаси и не очень. А пользователи в Excel ВПР делают из 2з таблиц 🤣🤣
Извращения и ошибочные решения можно практически в любой области придумать... Особенно елси их целенаправленно искать...
источник

IB

Igor Burobin in Qlik BI chat
Да это традиционный путь. Я очень много компаний видел которые по нему шли
источник

SP

Sergey Polekhin in Qlik BI chat
V N
А где в контексте было ЕДИНОЕ и для ВСЕГО?
Но ряд задач без этого решается гораздо сложнее...
Зачем же пытаться в крайности бросаться...
Переверну:
Для решения большинства задач в Qlik хранилище не является необходимостью. Оно лишь может упростить ряд задач выходящих за рамки Qlik. И то, если его уже кто-то создавал и потратил на это свои ресурсы. Создавать хранилище именно для Qlik - лишняя трата времени и сил.
А вот в PowerBI и Tableau без серьёзного внешнего движка на серьёзных задачах делать нечего. И чаще всего его делают в виде хранилищ
источник

VN

V N in Qlik BI chat
Sergey Polekhin
Переверну:
Для решения большинства задач в Qlik хранилище не является необходимостью. Оно лишь может упростить ряд задач выходящих за рамки Qlik. И то, если его уже кто-то создавал и потратил на это свои ресурсы. Создавать хранилище именно для Qlik - лишняя трата времени и сил.
А вот в PowerBI и Tableau без серьёзного внешнего движка на серьёзных задачах делать нечего. И чаще всего его делают в виде хранилищ
источник

SP

Sergey Polekhin in Qlik BI chat
А что вы хотите этим сказать?
источник

VN

V N in Qlik BI chat
Igor Burobin
Да это традиционный путь. Я очень много компаний видел которые по нему шли
ну если кто-то использует инструмент не по назначению, это не говорит о том что инструмент плохой...
источник

IB

Igor Burobin in Qlik BI chat
Все по назначению, просто целям он не соотвствует
источник

IB

Igor Burobin in Qlik BI chat
OLAP отличная технология, хранилки колоночные тоже
источник

VN

V N in Qlik BI chat
Sergey Polekhin
А что вы хотите этим сказать?
То, что есть задачи для которых это вполне себе уместно и желательно...
источник