Спасибо, это довольно важное замечание, хотя и не во всех СУБД такие ограничения есть (добавил в статью). Кстати, дефолтная глубина в MySQL 8.0 – 1000 (линк), причем это была новая фича релиза.
А при чем тут вообще дашборды? Во-первых, данные могут использоваться для разных целей. Во-вторых, современные BI системы позволяют набросать дашборд с фильтрами и без dimension таблиц. Если у вас база не проектировалась как хранилище данных – в ней таких таблиц и не будет.
Использование зарплат сHR-агрегаторов несет в себе вполне определенную проблему: вы анализируете не рыночные зарплаты как таковые, а зарплаты компаний, которые готовы их раскрыть. Чем выше зарплата, - тем менее охотно работодатели её указывают. Так что ваша оценка будет заниженной.
Чтобы такой сервис давал максимально точную оценку - нужны эксклюзивные данные по реальным заработным платам. Причем в первую очередь интересны не текущие зарплаты, а недавние наймы (т.е. текущий рынок). Например, украинский сайт для анонимного поиска работы джинн (djinni.co) предоставляет статистику по недавним наймам через телеграм бот (@djinni_jobs_bot). Пример использования: /howmuch middle python
Перевод хромает. Например, induced demand — индуцированный (устоявшийся перевод термина), или "спровоцированный" (свободный перевод) спрос. Но ни разу не "вынужденный", как в этом переводе.
Так, понимаю, вы в R использовали один из пакетов (ggplot2 или lattice), а не базовую графику? Ваш комментарий можно доработать до полноценной статьи, кстати )
Выражусь точнее: для тестов всё равно. Но naming convention в PosgreSQL (о котором шла речь) предполагает использование именно bigint, поэтому на практике лучше всегда писать именно так
Да, вы правы (я поменял оба пункта в статье). На счет типа данных: для этих тестовых данных достаточно int8 (хотя на практике действительно почти всегда будет нужен bigint).
А вы попробуйте написать проще. Если что, lag(total) over (order by dt) + val as total не работает: SQL не допускает обращения к столбцу до того, как он был объявлен.
Даже если оставить за скобками синтаксис (этот код нерабочий), в Excel мы используем заранее отсортированный список. К расчёту «как в Еxcel» ближе всего способ с MODEL в Oracle.
В большинстве случаев у нас будет поле, которое позволяет сортировать записи (будь то дата и время, id записи, и т.д. и т.п.). Дата в моих примерах – всего лишь упрощение, достаточное для туториала. Если нужного поля нет, то и нарастающий итог post-factum не посчитать никак.
Через LAG попросту нет элегантного решения. Понадобится CTE или процедура с циклом (и у меня есть сомнения, что это даст ускорение в сравнении с SUM() OVER …).
В SQL Server 2005 были исключительно оконные функции для ранжирования (т.е. ROW_NUMBER, RANK, DENSE_RANK, и NTILE). А полноценная поддержка с полным набором функций введена только в 2012.
mean(x = 1:100)x
… а теперь так:
mean(y <- 1:100)y
Или более общий пример (первые три выражения работают, на четвертом ошибка):
x <- y <- 1x = y = 2
x = y <- 3
x <- y = 4
Почему выбрали именно NiFi? Какие ещё альтернативы рассматривали?
Кстати, с такой постановкой задачи ("обеспечить загрузку данных по мере их изменения на источнике") был смысл использовать CDC инструменты.
Спасибо, это довольно важное замечание, хотя и не во всех СУБД такие ограничения есть (добавил в статью). Кстати, дефолтная глубина в MySQL 8.0 – 1000 (линк), причем это была новая фича релиза.
А при чем тут вообще дашборды? Во-первых, данные могут использоваться для разных целей. Во-вторых, современные BI системы позволяют набросать дашборд с фильтрами и без dimension таблиц. Если у вас база не проектировалась как хранилище данных – в ней таких таблиц и не будет.
Использование зарплат с HR-агрегаторов несет в себе вполне определенную проблему: вы анализируете не рыночные зарплаты как таковые, а зарплаты компаний, которые готовы их раскрыть. Чем выше зарплата, - тем менее охотно работодатели её указывают. Так что ваша оценка будет заниженной.
Чтобы такой сервис давал максимально точную оценку - нужны эксклюзивные данные по реальным заработным платам. Причем в первую очередь интересны не текущие зарплаты, а недавние наймы (т.е. текущий рынок). Например, украинский сайт для анонимного поиска работы джинн (djinni.co) предоставляет статистику по недавним наймам через телеграм бот (@djinni_jobs_bot). Пример использования:
/howmuch middle pythonПеревод хромает. Например, induced demand — индуцированный (устоявшийся перевод термина), или "спровоцированный" (свободный перевод) спрос. Но ни разу не "вынужденный", как в этом переводе.
Так, понимаю, вы в R использовали один из пакетов (ggplot2 или lattice), а не базовую графику? Ваш комментарий можно доработать до полноценной статьи, кстати )
lag(total) over (order by dt) + val as totalне работает: SQL не допускает обращения к столбцу до того, как он был объявлен.Могу предположить, что
SELECTвывел записи в порядке их добавления в базу. Без сортировки это поведение не должно быть гарантированнымMODELв Oracle.functools:А приз выдадут довольные клиенты (когда увидят perform вычислений на уровне приложения)
LAGпопросту нет элегантного решения. Понадобится CTE или процедура с циклом (и у меня есть сомнения, что это даст ускорение в сравнении сSUM() OVER …).