Data Craze Weekly #3

Tę wiadomość możesz otrzymać bezpośrednio na swoją skrzynkę dzięki zapisowi na newsletter – Data Craze Weekly.

Przegląd Tygodnia

Dzisiaj przygotowałem dla Ciebie jedną ciekawostkę i garść informacji ze świata danych.

Lateral JOIN

Będę z Tobą szczery, jak to się stało, że nie znałem tego złączenia nie wiem. Wiem jednak, że mam teraz do nagrania nowe wideo do kursu i aktualizacje w PDF-ach nt. join-ów.

Człowiek się całe, życie uczy i tak ostatnio wpadłem na składnie join lateral.

Okazuje się, że jest to a jakże element składni ISO dostępny m.in w Oracle, PostgreSQL, MySQL czy SQL Server (z użyciem APPLY).

Co takiego w nim wspaniałego? Ano pozwala nam na de facto zrobienie pętli w pętli. Jeżeli założym, że robią FROM (jakaś tabelka) wykonujemy pętle po wierszach w danej tabeli to lateral pozwala nam na zrobienie kolejnej pętli odwołując sie do elementów z nadrzędnego obiektu (to może być tabela, funkcja czy widok).

Czerpiąc wprost z dokumentacji:

LATERAL is primarily useful when the cross-referenced column is necessary for computing the row(s) to be joined.

Dokładne wyjaśnienie z przykładem w linku.

Link: https://www.cybertec-postgresql.com/en/understanding-lateral-joins-in-postgresql/

Projekty vs Produkty związane z danymi

Bardzo ciekawy tematy, jak zmienia się podejście do tematów związanych z danymi. Z podejścia projektowego (tickecik i jedziemy) do produktowego (co możemy zrobić mając dane żeby użytkownikom żyło się lepiej).

TL;DR - Projects have a clear definition of what needs to be delivered while products do not. This fundamentally changes how teams are incentivized and what it means to “do work”.

Link: https://medium.com/@claykarges/data-projects-vs-data-products-why-mindset-matters-c2a02fb7c165

O kontraktach w świecie danych

Czasy w których jedna osoba robiło wszystko – od projektu, po integracje ze źródłem danych po proces przetwarzania danych na warstwie wizualizacyjnej kończąc. Stety lub niestety przechodzą do historii.

A jak nowe czasy to i nowe pojęcia – data contract.

Czyli nic innego jak pewna umowa pomiędzy przynajmniej dwiema stronami (zwykle backendem i frontendem) nt. tego jak będzie wyglądał schemat danych – jakie atrybuty jakie typy danych, jeżeli zagnieżdżenia (jak JSON) to jakie itd.

Rzecz uważam bardzo dobra, tylko wykorzystywana mądrze (jak wszystko). Pamiętaj proszę, że takie rzeczy mają nam pomagać a nie wprowadzać dodatkową papierologię, dlatego stosujmy tam gdzie potrzeba, przy obopólnej zgodzie a wszystkim będzie żyło się lepiej.

Link: https://towardsdatascience.com/data-contracts-from-zero-to-hero-343717ac4d5e

Narzędzia

popsql – cytuję ze strony „Collaborative SQL editor for your team” hmm. Wyobraź sobie to, piszesz cudowny fragment kodu, a tutaj nagle komunikat, że Twój kolega lub koleżanka zamienia przecinki z końca na początek i cały nastrój do piachu 😁

A tak serio, to takie narzędzie ma swoje plusy. Możesz spokojnie je wykorzystać w rozmowie z analitykiem biznesowym (lub osobą z biznesu ogarniającą SQL-a) dać swoje pomysły, zerknąć na poprawki z drugiej strony. Dodatkowo pokaże Ci ładnie historię zmian, są plusy nie wątpliwie.

Natomiast gdy ktoś przez lata buduje swój styl pracy w jakimś IDE lub terminalu, może być ciężko przeskoczyć na takie narzędzie.

Link: https://popsql.com/

Sprawdź Wiedzę

#SQL Wyżej pisałem o LATERAL JOIN, to tutaj bez użycia tej konstrukcji.

Dla danych z tabeli WISHLIST znajdź 3 produkty (tabela PRODUCTS) spełniające warunek cenowy z wishlisty.

http://sqlfiddle.com/#!17/6f615/2: https://sqlfiddle.com/#!17/6f615/2

Więcej pytań z SQL znajdziesz tutaj: SQL - Q&A

Praca

• Pledge - Data Engineer – UK (London) – £55,000 – £80,000

Szukane umiejętności: Python, SQL, AWS Glue, Spark, Serverless._