Cześć !
Ogarnięciu jakiego tematu poświęciłaś/łeś najwięcej energii/czasu podczas nauki SQL ?
Cześć !
Ogarnięciu jakiego tematu poświęciłaś/łeś najwięcej energii/czasu podczas nauki SQL ?
Chyba nie żaden szczególny "atom" - raczej to, że złożoność kwerend rośnie bez żadnej strukturyzacji, jeden wielki main()
czy basic na Spectrum
Dla mnie najtrudniejsze z zwykłym SQL są skomplikowane selecty gdzie są związki wiele do jednego albo wiele do wielu z jakimiś grupowaniami itp
Największym wyzwaniem był moment przejścia z robienia prostych zapytań z małej bazki, którą postawiłem na swoim komputerze do pracy z korporacyjną bazą z ok. tysiącem tabel.
Może nie najtrudniejsze, ale uciążliwe jest to, że nie korzystam z niego na co dzień i gdy pojawia się zagadnienie wymagające czystego SQL, to muszę sobie przypominać kwerendy i początkowo drapię się w głowę na zagadnieniami, które okazują się całkiem proste.
U mnie najwięcej czasu pochłania plsql a raczej rozkminy czy jest możliwość w łatwy sposób wykonania dość skomplikowanych operacji na danych w procedurze czy trzeba klepać ręcznie rozwiązania.
Jeśli szukasz inspiracji do jakiegoś tematu, który będzie jednocześnie w miarę ambitny oraz może się ludziom przydać to możesz napisać coś o łączeniu danych z różnych baz. W Postgres jest to pod hasłem Foreign Data
- https://www.postgresql.org/docs/9.3/ddl-foreign-data.html. Sam aktualnie jestem na etapie rozgryzania o co w tym chodzi i chętnie posłucham/poczytam informacji w tym zakresie od kogoś z doświadczeniem w takich zabawach.
W szczególności mógłbyś napisać:
możliwość w łatwy sposób wykonania dość skomplikowanych operacji na danych w procedurze czy trzeba klepać ręcznie rozwiązania
Tutaj bym jeszcze dodał kwestię, jak ocenić, co się bardziej opłaca. Czy zarzynać serwer skomplikowanym zapytaniem, czy lepiej pobrać więcej danych i je przefiltrować po stronie frontu/aplikacji klienckiej. Jak rozpoznać, kiedy które rozwiązanie jest lepsze, jakie są w tym zakresie wytyczne oraz "dobre praktyki".
Analiza planów zapytań. Kilka razy się do tego zabierałem, ale mi nie wychodzi. Co prawda przy zapytaniach z kilkoma joinami jakoś sobie radzę, ale analiza planu zapytania złożonego (funkcje okna, subselecty, grupowania, unie i to wszystko na raz) już nawet się nie zabieram do analizy, tylko klikam opierając się o "intuicję".
Z mojej perspektywy było to zdecydowanie partycjonowanie tabel - musiałem utworzyć tabelę, która przechowa miliardy punktów (lat,lon). Najpierw utworzyłem partycje po szerokości geograficznej i dla każdej takiej partycji utworzyłem kolejne partycje po długości geograficznej.
Wydaje się proste, ale przy tak dużej tabeli wychodzą od razu wszystkie wady indeksów i na co trzeba uważać. Uczysz się automatycznie analizować zapytania (Przykładowo EXPLAIN ANALYZE w postgres) Bez tego po prostu nie jesteś w stanie stwierdzić czy Twoje zapytania odpytują odpowiednie partycje, czy używają odpowiednich indeksów.
Możesz przykładowo zrobić PoC partycjonowania. Zapisać setki milionów punktów geograficznych do bazy i poeksperymentować :)
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.