Pomysł na dzisiejszy wpis zerżnąłem (zresztą nie po raz pierwszy) od Johna: https://www.johndcook.com/blog/2017/09/30/how-many-musical-scales-are-there/
Analogicznie do chlebaka, który jak powszechnie wiadomo służy do noszenia granatów, oktawa, jak sama nazwa wskazuje, składa się z dwunastu półtonów.
To znaczy tak: półtonów jest rzeczywiście dwanaście, ale dźwięków tylko osiem.
Już w latach 90 zeszłego stulecia firma Postgres próbowała zrealizować ideę tabel temporalnych, jednak ze względu na bardzo wysokie koszty składowania ogromnych ilości danych pomysł zarzucono.
W roku 2013 tabele temporalne trafiły do kolejnej wersji specyfikacji języka SQL.
Od niedawna wszyscy więksi dostawcy baz danych przejęli się tematem i zaczęli implementować tę opcję w swoich produktach. Jak na razie udało się to kilku firmom: Oracle, Postgres, Teradata, IBM DB2, Microsoft, Cockroach DB oraz MarkLogic (ten ostatni nie jest bazą stricte SQL-ową, ale mimo wszystko zaimplementowali „temporalność” w swoim produkcie).
Praca programisty jest – przynajmniej w teorii – fajna, prosta i przyjemna. Dostajemy projekt, dostajemy dokumentację, z której jednoznacznie wynika co mamy na wejściu i co chcemy dostać na wyjściu, siadamy, piszemy kod, testujemy kod, prosimy kilku użytkowników, żeby przetestowali wyniki i jak wszyscy są zadowoleni, wrzucamy kod do ogólnego użytku, wystawiamy fakturę i voila, gotowe.
A zaraz potem przybiega pierdzący tęczą jednorożec w towarzystwie reniferów, Świętego Mikołaja i uczciwego polityka…
Dziś prościutki trick pomocny wszystkim piszącym duże ilości kodu SQL.
Jak wszyscy wiedzą[citation needed] w Visual Studio można tworzyć regiony kodu, czyli takie bloki, które automatycznie „dostają” na marginesie edytora ikonkę minusika w kwadraciku (po naszemu: minusa w kwadracie), umożliwiającą „zwinięcie” całego bloku do jednej linii.
Algorytm postępowania w przypadku natrafienia na komunikat błędu:
Dziś pokażę, jak można rozwiązać zagadkę o gwoździach Wilsona za pomocą SQL-a.
Rozwiązanie nadesłał jeden z Czytelników. Pozwoliłem sobie nieco sformatować i uporządkować kod, jednak ogólną logikę rozwiązania pozostawiłem bez zmian.
Operatory analityczne są często traktowane po macoszemu przez padawanów sztuki SQL-owej. Czasem jednak potrafią one zaoszczędzić mnóstwo czasu. Dziś pokażę, jak działa operator LAG.
Jednym z klasycznych problemów, przed którymi staje większość programistów SQL, jest wykonanie zestawienia, w którym chcemy pokazać wartości z rekordu bieżącego wraz z wartościami z rekordu poprzedniego, w jednym rekordzie.
Typowym podejściem jest tu utworzenie CTE z ROW_NUMBER(), a następnie wykonanie JOIN-a tego CTE z samym sobą po kolumnie ROW_NUMBER() z nią samą zmniejszoną o jeden. Czyli po naszemu tzw. self-join.
Od czasu do czasu każdego z nas nachodzi nagła potrzeba wyliczenia skrótu z jakiejś dużej wartości tekstowej. To znaczy, nie dużej, tylko długiej. Ale nachodzi, prawda?
Jeżeli, Czytelniku, nie nachodzi Cię od czasu do czasu nagła potrzeba wyliczenia du… dług.. skrótu z jakiejś długiej wartości tekstowej, ten wpis prawdopodobnie nie jest dla Ciebie – polecam zamiast tego odwiedzić Joe Monstera, Nowego Pompona czy choćby Siupy z Dupy.
Tych z Czytelników, którzy od czasu do czasu walczą z przemożoną chęcią haszowania długich stringów, zapraszam do dalszej lektury.
Przeczytałem dziś na moim ulubionym portalu informacyjnym, że Microsoft szykuje się do wypuszczenia linuksowej wersji SQL Servera.
Dla pewności łyknąłem flaszkę Ritalinu, dźgnąłem się w łydkę widelcem, a także poprosiłem kolegę, żeby mnie uszczypnął (na co kolega zareagował dość podejrzliwie – nadmiar bliskości w, za przeproszeniem, stosunkach biurowych, nigdy nie jest zbyt mile widziany).
Upewniwszy się, że nie śnię, zabrałem się za lekturę.
Dziś pchełka dotycząca optymalizacji operatora MERGE.
Uwaga: jeżeli nie wiesz, jak działa MERGE, lub po prostu nie interesujesz się bazami danych, ten wpis raczej nie jest dla Ciebie. Istnieje szansa, że uśniesz w okolicach czwartego akapitu…
Mamy następujący scenariusz: ładujemy dane do hurtowni. W pierwszej kolejności ładowana jest warstwa STAGE a następnie warstwa EDW.
Rozwiążemy sobie dziś problem, który w Excelu rozwiązuje się dość prosto, natomiast w SQL-u odrobinę trudniej (ale bez przesady). Spróbujemy też odpowiedzieć sobie na pytanie, która z pokazanych metod jest najbardziej wydajna.
Pchełki SQL są na tym blogu od jakiegoś czasu traktowane po macoszemu – trochę z braku czasu, trochę z braku pomysłów, a trochę z najnormalniejszego, ludzkiego lenistwa.
Dziś nadrobimy tę zaległość. Napiszemy króciutko o funkcji skrótu oraz konwersji skrótu na tekst.