wstęp do baz danych na przykładzie Airtable

Miłosz Bolechowski

czas czytania: 10 min
Poniższy artykuł pojawił się na stronie 3.05.2019 roku i był dostępny dla Patronów z najwyższego progu („jestem tu na poważnie”) — teraz jest dostępny dla wszystkich, żeby ci z Was, którzy chcieliby rozpocząć ułatwianie sobie pracy przy użyciu narzędzia Airtable, mieli taką możliwość. Miłego czytania!

Gdy istnieje potrzeba zapisania sporej ilości różnych informacji, w pierwszej kolejności najczęściej myśli się o arkuszu kalkulacyjnym. Tego się uczy w szkołach, tego używa się w biurach, więc pewnie nie jest to taki zły pomysł. I choć rzeczywiście przodujące aplikacje do pracy nad arkuszami kalkulacyjnymi znacznie się rozwinęły na przestrzeni ostatnich kilku lat, zwłaszcza w zakresie sortowania czy filtrowania danych, to jednak nadal daleko im do baz danych — narzędzia często dużo bardziej odpowiedniego. Czasem wydaje mi się, że połowa arkuszy kalkulacyjnych powinna być tak naprawdę bazą danych właśnie, bo to ułatwiłoby wiele operacji użytkownikowi, ale jednak bazy danych od zawsze traktowane są jako „te trudne” (być może bierze się to stąd, że myśląc o bazie danych często widzi się przed oczami Microsoft Access, który przez lata rzeczywiście odpychał od siebie i interfejsem, i sposobem obsługi).

Dziś chciałbym Wam jednak przybliżyć nieco ten temat, żeby w kolejnych tekstach móc się odnosić do podstaw, które znajdziecie poniżej — wybaczcie więc ten akademicki tytuł, ale wydaje mi się, że w ten sposób będzie po prostu łatwiej. I już w tym miejscu nadmienię, że choć poniższe przykłady mogą wydać się niepotrzebne zawodowemu fotografowi, to obiecuję, że jako całość (tj. ten i pewnie dwa kolejne teksty) będzie to miało sens.

Od dawna planowałem przenieść dane z jednego ze swoich — a jakże — arkuszy kalkulacyjnych do Airtable, webowej aplikacji, której używam od nieco ponad dwóch lat, głównie do zarządzania informacjami o swoich parach, o czym nadmieniałem w kilku miejscach już wcześniej. Tym razem chodziło jednak o listę …posiadanych przedmiotów. Głównie elektroniki, choć nie tylko. I na dobrą sprawę nie tylko przedmiotów, bo oprogramowanie też się tam znajduje. Arkusz zawierał daty zakupu i liczył ile czasu minęło od tego dnia.

To często mi się przydaje, gdy w tekście odnoszę się do jakiegoś sprzętu czy aplikacji, pisząc, że używam go czy jej od x czasu. Czasem pomaga mi to także w decyzjach zakupowych, gdy widzę np. że para butów biegowych starcza mi średnio na ponad 3,5 roku (pewnie dlatego, że nie używam tylko jednej) albo, że komputer wystarcza u mnie na prawie 4 lata.

Tak czy inaczej, uznałem, że skoro będę tworzył taką bazę od zera (mógłbym zaimportować istniejący arkusz, ale zbyt wiele rzeczy chciałem zmienić), to pokażę Wam krok po kroku, wyjaśniając co i po co robię.

Na początku tworzę nową bazę w Airtable — nadaję jej nazwę, ikonę i kolor (który będzie też kolorem nagłówka wszystkich późniejszych widoków).

Airtable tworzy wówczas pierwszą tabelę z trzema pustymi „rekordami” (bo tak nazywa się „wiersze” w bazie danych) i trzema podstawowymi polami — nazwą, notatkami i miejscem do dodania załącznika (to ostatnie już teraz odróżnia tę bazę od arkusza kalkulacyjnego, a różnic będzie znacznie więcej).

Zmieniam nazwy pól i ich kolejność, tak, żeby odpowiadały moim potrzebom (mógłbym je, oczywiście, usunąć — nie są obligatoryjne — ale akurat wszystkie trzy będą mi potrzebne).

Następnie dodaje kolejne pola, wybierając z długiej listy ich rodzajów:

Potrzebna mi będzie data zakupu, więc rodzajem pola, rzecz jasna, będzie data, a jej formatem — również rzecz jasna (bo tak działa mój mózg) — ISO, czyli 2019–05–01, bez godzin:

W identyczny sposób dodaję pole data sprzedaży, bo i tę chciałbym monitorować, żeby wiedzieć jak długo używałem danego przedmiotu.

Następne pole to formuła — to ona zajmie się liczeniem czasu, jaki minął od daty zakupu. Używam do tego DATETIME_DIFF, gdzie parametrami jest pole data zakupu, stała TODAY() oraz ’days’ jako wybór formatowania wyniku. Formuła ma więc podać ilość dni jaka minęła od dnia zakupu do dziś (tj. do dnia, w którym zaglądam do bazy).

W przykładzie powyżej wynikiem jest „–20”, więc do wcześniejszej formuły dodaję jeszcze pomnożenie całości przez „–1”:

Choć, gdy teraz o tym myślę, to zamiana daty zakupu i TODAY() miejscami dałaby ten sam efekt, ale teraz przynajmniej wiecie, że w polu formuł można je zagnieżdżać tak samo jak w Excelu czy Numbers.

Wynik jest już bez minusa, ale pojawia się inny problem. W przykładzie wpisałem datę sprzedaży, a formuła nadal liczy czas, tak, jakbym nadal tego czegoś używał. Nie mogę w formule podać daty sprzedaży, bo przecież nie każdy przedmiot będzie ją miał. Mógłbym wprawdzie zagnieździć tam instrukcję warunkową IF, ale nie chciałem niepotrzebnie komplikować samej formuły (zwłaszcza, że pole do jej edycji jest raczej niewygodne przy kilku wierszach). Wspomogłem się więc osobnym polem, które nazwałem date_for_formula:

I to właśnie tam osobna formuła sprawdza czy pole data sprzedaży nie jest puste (bo jeśli nie jest, to bierze z niego datę) czy właśnie jest puste; wówczas bierze pod uwagę datę z pola data zakupu. I teraz pozostaje mi już tylko ukryć to pole (do niczego nie będzie już potrzebne), a w formule z pola dni zmienić datę zakupu na date_for_formula:

Pole dni sprawdzi się przy świeżych nabytkach, ale co z tymi, których używam od lat? Przyda się więc jeszcze jedno pole, która wyświetli ten sam okres w latach. Najprościej byłoby zduplikować pole dni, a następnie zmienić parametr days na years.

Niestety, funkcja ta zlicza wówczas tylko pełne lata (tj. zarówno 367 dni, jak i 650 dni będzie wyświetlone jako „1”) i nawet jeśli w formatowaniu zmieni się wyświetlanie tej wartości z np. dwoma miejscami po przecinku, nadal pozostanie „1.00”.

Dlatego zostawiam parametr days i dzielę wszystko przez 365 (choć pewnie bardziej poprawnie byłoby podzielić przez 365,25):

Zostawiam tam jedno miejsce po przecinku (na zrzutach zostawiłem dwa, ale potem uznałem, że nie potrzebuję aż takiej dokładności) i przechodzę do stworzenia kolejnego pola — cena zakupu:

Zmieniam tam symbol waluty na PLN i dodaję do niego spację (wyświetla się on przed wartością i nie można tego zmienić, więc choć $99 wygląda dobrze, tak PLN99 już — moim zdaniem — nie). W ten sam sposób dodaję cenę sprzedaży. Nie potrzebuję tych danych do niczego poza samą informacją — często, po latach, nie pamiętam ile coś kosztowało mnie w przeszłości lub za ile coś udało się sprzedać (sprawdzając tym samym utratę wartości), więc dobrze będzie mieć to w jednym miejscu.

Kolejne pole to tagi — przyda się do późniejszego grupowania czy filtrowania. W Airtable nie trzeba wszystkich tagów wymyślać na etapie tworzenia pola — dodając kolejne przedmioty do bazy, wpisanie nowego tagu automatycznie go utworzy. Tagi mogą być kolorowe (a kolory można ręcznie edytować) i, oczywiście, można wybrać ich kilka do każdego rekordu:

Zaczynam więc wpisywać te sprzęty, które miałem w swoim starym arkuszu (a wpisywać można zarówno w widoku kolumn, jak i w widoku pojedynczego rekordu) i po kilku chwilach baza wygląda tak:

Teraz czas na eksport zdjęć z Lightroom, a że tam wszystkie zdjęcia mam opisane słowami kluczowymi, również zajmuje to tylko chwilę.

Przy okazji; ktoś móglby zapytać dlaczego te wszystkie zrzuty pochodzą z macOS, skoro częściej używam iOS. Istotnie, choć Airtable na iOS — jako aplikacja — wciąż jest okrojona, zwłaszcza w zakresie tworzenia nowych baz (nie ma możliwości dodawania pól niektórych typów, w tym właśnie formuł). Do dziś nie można też zobaczyć na iPadzie widoku galerii, który na Maku wygląda tak:

W ten oto sposób dotarliśmy do największej różnicy między arkuszami a bazami danych — te drugie pozwalają na niemal dowolne filtrowanie, sortowanie i nawet różne prezentowanie zawartości. Widok galerii jest tu świetnym przykładem — moim zdaniem całkowicie zmienia on sposób postrzegania takiej bazy. Airtable pozwala w nim na wybór, które dane mają się wyświetlić pod zdjęciem, więc i to można dostosować do własnych potrzeb.

Sam widok tabeli daje jeszcze więcej możliwości; nie tylko można sortować, podając kilka parametrów (np. najpierw po dacie, potem po nazwie), ale także grupować np. po tagach:

Całość można też filtrować (to moja ulubiona rzecz w Airtable), a przefiltrowany widok zapisać, żeby mieć do niego łatwy dostęp. Zatem wystarczy kilka kliknięć (lub tapnięć, bo to można także na iPadzie), żeby utworzyć sobie np. takie widoki:

  • wszystkie produkty Apple, posortowane od najnowszych,
  • to samo, co wyżej, ale wyłącznie te, które nadal są w użyciu (filtrując za pomocą pola data sprzedaży, tj. pokazując wyłącznie te pozycje, w których to pole jest puste),
  • tylko produkty fotograficzne, tj. zawierające tag „aparat”, „obiektyw” lub „fotograficzne” (w domyśle „akcesoria”), posortowane od tych, których używam najdłużej,
  • tylko komputerowe — podobnie jak wyżej; zawierające tag „komputer” lub „komputerowe”, przefiltrowane tak, żeby pokazał tylko te, które nadal są w użyciu,
  • kupione w ciągu ostatniego roku (przydatne do „cudawianków” :),

(W ostatnim zrzucie kilka pozycji ukryłem, żeby nie pokazać Wam o czym piszę dla Was w wolnych chwilach :)

I skoro można je utworzyć na iPadzie, to są one oczywiście widoczne z jego poziomu:

Co ważne; każdy widok może mieć swoją własną kolejność pól, a także w każdym z nich można inne pola ukrywać. Innymi słowy; z tej przepastnej tabeli można wybrać sobie tylko to, co do danego widoku jest konieczne.

Ale to nie wszystko; każda kolumna ma swoje podsumowanie:

I to podsumowanie może być zarówno sumą, jak i średnią lub wartością maksymalną/minimalną czy nawet histogramem (opcji jest naprawdę sporo):

Co to daje? Tak, jak wspomniałem powyżej — dzięki temu mogę zobaczyć np. jak często zmieniam komputery:

Albo po jakim czasie średnio sprzedaję obiektywy:

Albo ile kosztowały mnie produkty kupione w ubiegłym roku (dla Waszego dobra nie umieszczam zrzutu :)

W międzyczasie pomyślałem też, że przyda się jeszcze jedno pole — numer seryjny. Dotychczas te informacje miałem w notatce w 1Password, ale uznałem, że większy sens będzie przechowywanie wszystkiego w jednym miejscu.

Jest jednak kilka rzeczy, których Airtable nie potrafi. Na przykład; nie jest w stanie wyekstrahować z pola data zakupu samego roku. Chciałbym mieć widok, w którym wszystkie przedmioty byłyby pogrupowane pod względem roku, w którym były kupione i, żeby to zrobić trzeba to trochę obejść, tworząc kolejne pole z formułą YEAR(), gdzie parametrem jest, oczywiście pole data zakupu (pole może być ukryte):

Podobnie jak jedna z nowszych wersji Numbers, tak i Airtable pozwala na formatowanie warunkowe (czyli np. niech wszystkie przedmioty, których używam dłużej niż 3 lata będą zaznaczone na zielono), ale niestety tylko w płatnej wersji, a ta kosztuje aż 20€ miesięcznie.

Potrafi za to udostępniać utworzone wcześniej widoki, więc poniżej znajdziecie dwa linki, w których sami możecie filtrować i sortować udostępnione widoki:

widok galerii

widok tabeli pogrupowanej latami

Na podobnej zasadzie udostępniam kilka widoków swoim stałym klientom, gdzie mogą znaleźć wszystkie ostatnie zlecenia i wiedzą jakiej faktury się spodziewać.

Powyższa baza to tylko jeden z przykładów. W podobny sposób przechowuję informacje o przeczytanych książkach czy ciekawych odcinkach podcastów, które słucham (ta ostatnia baza jest ciekawa o tyle, że dane do niej — za pośrednictwem API — wpisuje shortcut, automatycznie wyciągając je z Overcast). W następnym artykule pokażę jednak to, do czego Airtable służy mi jako fotografowi, co pewnie przyda Wam się bardziej.

oprogramowanieautomatyzacjaairtabledarmowe

dyskusja