“No to paczka zaczyna nagle lecieć do Mozambiku.” 🎯 Tak kończy się współdzielona tabela adresów. Na start nowego formatu Szymon wyciąga pytanie rekrutacyjne starsze niż połowa juniorów i przepytuje Łukasza z modelowania danych dla firmy kurierskiej typu UPS.
Adres siedzi w około 100 miejscach, a do dyspozycji jest baza relacyjna. Łukasz zaczyna od odrzucenia trzeciej postaci normalnej, potem godzi się na duplikaty, a na koniec proponuje nowy rekord przy edycji. Szymon odpowiada selectem na około 100 joinów w transakcji. Skaluje się pięknie. Na slajdzie.
Partycjonowanie po kraju? Szymon wyciąga Somalię i Somaliland, a Łukasz ripostuje: “uważam, że to jest overengineering teraz w tym miejscu”. Kluczowe pytanie brzmi: jaka jest funkcja równości adresów? Według Szymona: “Czy pan listonosz umie tam dostarczyć?”
Puenta: adres nie ma tożsamości encji, to value object, więc “to nie może istnieć jako tabela, bo ten nasz ID będzie sztuczny”. Do tego denormalizacja, sharding po sensie biznesowym i faktura jako niezmienny dokument. Czy Twoja tabela addresses modeluje świat rzeczywisty zamiast domeny biznesowej? ⚠️
Linki i ciekawe znaleziska
Transkrypcja
Szymon Warda: To jest pytanie, które pokazuje, jak ludzie myślą, a niekoniecznie to, jaki jest wynik. To nie może istnieć jako tabela, bo ten nasz ID będzie sztuczny. Najgorszym błędem, który ja często właśnie widzę, to są takie rzeczy modelowanie na zasadzie: a to zróbmy sobie bardzo sztywny system na zasadzie słowników albo modelujemy świat rzeczywisty. Tylko żaden biznes nie operuje w świecie rzeczywistym, tylko operuje na tym, co potrzebuje ze świata rzeczywistego, upraszcza to.
Łukasz Kałużny: Modeluje na swojej domenie biznesowej. Trzeba znać fuckupy w domenie, w której pracujemy. Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Co dzisiaj, Łukaszu? Dzisiaj Cię przepytujemy.
Łukasz Kałużny: Dzisiaj eksperyment. Dzisiaj eksperyment powrotu do tematów, które na co dzień powinny budować model mentalny, żebyście umieli rozwiązywać problemy. Jeżeli to wejdzie, zrobimy sobie z tego całą serię. A dzisiaj chyba taki pierwszy test, czyli modelowanie danych, bo to jest temat, do którego się odnosimy wielokrotnie i wielokrotnie padają pytania, co my w ogóle przez to mamy na myśli i jak o tym myśleć.
Szymon Warda: Dobrze, to teraz Łukasz tego nie wie, bo specjalnie, mimo że się parę razy dopraszał, nie powiedziałem mu co i jak. I trochę wstępu historycznego. Bo ja mam takie jedno pytanie właśnie o modelowanie danych. To pytanie ma brodę, za chwilę będzie pełnoletnie praktycznie. I żeby to było jasne, to jest pytanie, które pokazuje, jak ludzie myślą, a niekoniecznie to, jaki jest wynik. I sobie przez nie przejdziemy w ogóle. Więc taka ciekawostka. Ponownie, ponownie to pokazuje po prostu jak ważne modelowanie i jak się patrzy, jak się wychodzi z problemu.
Łukasz Kałużny: Dobrze, to jak brzmi to pytanie magiczne, którego nie chciałeś mi w ogóle przekazać?
Szymon Warda: Nie chciałem Ci, bo jestem wredna bestia.
Chłopaki z Baraków: Praca strażnika to niełatwy chleb. W większości się nie udaje przebić w tej branży. Poddam Was testowi na inteligencję, sprawność fizyczną i psychologiczną.
Szymon Warda: Dobrze Łukaszu, załóżmy, że modelujemy sobie system dla firmy kurierskiej, na przykład UPS. Kojarzysz? Kojarzysz. Podczas analizy wyszły nam dwie ważne rzeczy. Pierwsze to, że klient w obecnym systemie miał pierdolnik jeżeli chodzi o nazywanie adresów. Więc teraz chcesz, żeby adres to wszędzie to była ta sama encja, tak samo wyglądało i tak dalej. Drugie, co nam wyszło, to jest to, że adres jest wykorzystany w wielu miejscach, około 100 jak nie więcej. Masz adres na paczce, adres na kurierze, adres na użytkowniku, faktura ma adres odbiorcy, nadawcy i tak dalej, i tak dalej. Jak byś to zamodelował na bazie relacyjnej? Dla uproszczenia, żeby się już w noSQL-a nie bawić.
Łukasz Kałużny: Dla uproszczenia, tak, noSQL-a, to na relacyjnej powinieneś sobie zrobić tę nie trzecią postać normalną, bo to jest proszenie się o problemy, tylko będziesz miał jedną tabelę, ale bez deduplikacji, gdzie będziesz miał ID i będziesz miał po kolei wszystkie kolumny, które odpowiadają prawidłowym adresem.
Szymon Warda: Dobrze, może być. Lećmy w takim razie z tym podejściem. Dobrze, to teraz mamy sobie, mamy sobie paczkę, no nie, mamy sobie też na przykład jeszcze, na przykład mamy też fakturę. Czyli w takim razie jak to wygląda? Na przykład załóżmy mamy adres użytkownika i jest pani Anna, jest pan Jan. Anna mieszka we Wrocławiu, Jan mieszka w Krakowie. Przeprowadził się do Warszawy. Poznali się. Zamieszkali razem. Weszli na stronę UPS. Weszli na swój profil. Zmienili adres na ten sam, tą samą wartość wpisali dokładnie. To to u ciebie to będzie ten sam adres czy taki sam adres?
Łukasz Kałużny: Ten sam, czyli nowy wiersz.
Szymon Warda: Nowy wiersz, ale, czyli obydwoje będą mieli ID…
Łukasz Kałużny: Różne ID, będą mieli różne ID.
Szymon Warda: Czyli każdy, czyli będą mieli taki sam adres de facto. Czyli będą mieli duble w…
Łukasz Kałużny: Duble w tabeli, tak.
Szymon Warda: Tabeli. Dobrze. No to teraz możemy sobie łatwo policzyć, jaka będzie długość naszej tabeli z adresami, bo to będzie suma liczności wszystkich tabel, które wykorzystują adresy.
Łukasz Kałużny: No właśnie i to się zaczyna robić, bo wiesz, patrząc się na to masz śmieszne problemy, które wychodzą z tym, czyli ilość miejsc i aktualizacji.
Szymon Warda: Tak, czyli generalnie można powiedzieć śmiało, że nasza tabela adresowa to będzie najdłuższa tabela, o rząd wielkości minimum, niż jakakolwiek inna tabela w bazie.
Łukasz Kałużny: Poza order… Inaczej, pytanie jest jak z zamówieniami będzie? Bo zamówienia będą, tabela przesyłek będzie najdłuższa. To będzie druga najdłuższa.
Szymon Warda: No niekoniecznie. Ok, to idziemy w takim razie, zamówienie. Zamówienie generalnie ma swój, ma ID-ka unikalnego. Czyli powiedzmy wpis w zamówieniu będzie miał referencję do adresu unikalną czy jak to będzie wyglądało?
Łukasz Kałużny: Teraz musiałbym sobie to rozrysować, bo to nie jest takie. To jest cwane pytanie, wiesz. Jeżeli teraz popatrzymy, w zależności, bo masz… Rozbijmy sobie część, która jest najgorsza, może tak, zaczynając od reverse engineering adresu. Bo w teorii jest to, mamy, jak mówimy o Polsce, masz tam zunifikowaną bazę adresów, którą znasz. Jest w niej pierdolnik, jest w niej… Ludzie, którzy to korzystają, znają problemy, które tam występują. I najbardziej gorszą rzeczą to jest numer budynku i mieszkanie, które jest. I teraz…
Szymon Warda: Wydaje mi się, że tam jest dużo więcej gorszych rzeczy, ale…
Łukasz Kałużny: Nie, to są moim zdaniem takie najgorsze, jak popatrzysz, bo teraz jest pytanie jak modelujesz ten adres? Czy będzie to mieszkanie, czy nie i co będziesz robił w trakcie update’u oraz…
Szymon Warda: Do tego jeszcze wrócimy. Wracamy, realnie w tabeli adresowej masz unikalne rekordy czy wiele rekordów, w sensie wiele rekordów do jednego unikalnego wiersza odwołuje się, czy rekord ma swój wpis w tabeli adresowej?
Łukasz Kałużny: Pytanie, dobra, i teraz załóżmy co zrobisz, bo masz numer mieszkania. To oznacza, że powinieneś mieć per mieszkanie unikalny rekord to jest jeden ten. Druga sprawa oznacza to, że przy zamówieniu masz uwagi dla kuriera, itepe, itede.
Szymon Warda: Uwagi (…).
Łukasz Kałużny: Są, powinny być w paczce, o tak powinny być na…
Szymon Warda: Tak, w paczce.
Łukasz Kałużny: W paczce. I to wtedy by prowadziło… Co jeżeli jest jedno głupie pytanie? Co jeżeli ktoś zrobi błąd i to poprawia?
Szymon Warda: Szybko i konkretnie. Daj suba i notyfikację, nam to dużo ułatwia. Tam jest trochę więcej problemów, ale…
Łukasz Kałużny: Ale to jest, takie są główne, jak tak na szybko myślisz.
Szymon Warda: To wracamy w takim razie, wracamy w takim razie do tego tematu właśnie, mamy sobie panią Annę i pan Jan. Oni mają ten sam ID adresu. Nie, u Ciebie było, że osobne mają, osobne mają wpisy. Dobra, to w takim razie jak jest z paczką? Bo załóżmy paczka ma też swoją historię paczki, wiadomo, jak to przechodziło. Więc paczka jako taka ma unikalny czy ma każdy wpis w historii w paczce, zamówieniu, jak to nazywasz? To będzie…
Łukasz Kałużny: To będzie, to jest ciekawe w tym miejscu, bo…
Szymon Warda: Łukasz, to pytanie ma lekką ręką 10 lat. Więcej.
Łukasz Kałużny: Tak, bo jak sobie popatrzysz… Inaczej, jak zrobimy, bo problem jest taki, największy problem jest taki, bo adresy są w teorii unikalne, więc można byłoby ich nie deduplikować.
Szymon Warda: Tak, można by.
Łukasz Kałużny: Można by. Zabawa zaczyna się to, co jest źródłem prawdy. Jeżeli źródłem prawdy są dane od użytkownika, to jeżeli, właśnie, jeżeli by poprawiał, to masz problem. Bo co? Innym też poprawiasz?
Szymon Warda: Dochodzisz do tego właśnie elementu. Ale to zahaczymy o jedną rzecz, którą ruszyłeś w tym momencie. Bo Ty mówisz o unikalności. Unikalność sprowadza się też matematycznie do możliwości porównania. Czyli dwie rzeczy są takie same, czyli odwrotność unikalności, jeżeli są sobie równe. Jaki jest element równości adresu? Załóżmy ja mieszkałem na Alei Jerzego Waszyngtona. I teraz masz zapis taki: Al. Waszyngtona, Jerzego Waszyngtona, Al. Jerzego Waszyngtona, Waszyngtona. To są cztery zapisy, które są sobie…
Łukasz Kałużny: Równe.
Szymon Warda: No właśnie, ale nie są sobie równe. To w takim razie jaka jest funkcja równości adresów? Kiedy adresy są sobie równe?
Łukasz Kałużny: Jeżeli, właśnie widzisz i teraz tak, lecimy, bo pierwszym wyznacznikiem lecąc to jest kod pocztowy.
Szymon Warda: Który możesz wpisać orientacyjnie.
Łukasz Kałużny: Tak, orientacyjnie. Ale wiesz. I teraz jest pytanie czy normalizujemy się do źródła danych? Bo zobacz, że część teraz, dlatego ja powiedziałem trochę o source of truth. To zależy czy Ty masz bazę adresową, którą bierzesz oficjalną…
Szymon Warda: Ale ja nie powiedziałem, że operujemy w Polsce. Mamy UPS, firma międzynarodowa.
Łukasz Kałużny: Dobra, UPS. No i w tym momencie to jest problem jak to porównać.
Szymon Warda: Jest problem, ale jest jedna funkcja, która realnie porównuje to. Czy pan listonosz umie tam dostarczyć? Zdajesz sobie sprawę, że to jest funkcja porównania adresów: czy ktoś umie tą paczkę dostarczyć? Bo ten problem ostatniej mili, jak jest często nazywany, jest problem tego, czy człowiek, białko dostarczy na ten adres, bo te adresy są napisane różnie, ludzie gryzmolą i tak dalej, i tak dalej, i tak dalej.
Grzegorz Brzęczyszczykiewicz: Grzegorz Brzęczyszczykiewicz. Brzęczyszczykiewicz. Grzegorz.
Łukasz Kałużny: No tylko mówimy o elektronicznej.
Szymon Warda: Tak, tak, ale masz, możesz pójść sobie do UPS. Mówisz, że chcesz nadać paczkę. Pani da Ci kartkę, świstek i sobie nadasz paczkę. Teraz wracamy do tej naszej paczki. To jak z tymi adresami? One mają unikalny rekord czy one dublują te rekordy? Cisnę Cię, cisnę Cię.
Łukasz Kałużny: Cisnę, ale nie, to wiesz w tym wypadku…
Szymon Warda: Bo to pokazuje też (…) model (…).
Łukasz Kałużny: Dlatego wiesz, masz problem z tym, jest trudne, bo zobacz, że masz duplikat… Bo jeżeli przypiszesz do tych samych i użytkownik to poprawi, to nie możesz innemu userowi tego zmienić.
Szymon Warda: Zgadza się jak najbardziej.
Łukasz Kałużny: Więc mógłbyś podchodzić do tego tak, że jeżeli jest taki sam to nie, ale jeżeli ktoś zrobi poprawkę, edytuje to powinieneś założyć na przykład nowy dopiero wtedy.
Szymon Warda: Zgadza się. Czyli co, idziesz tą opcją generalnie, że jednak masz i że jednak masz te unikalne i jak jest edycja, to…
Łukasz Kałużny: To na przykład dodajemy nowe.
Szymon Warda: Dobrze. No to teraz idziemy jakby to miało działać. Czyli realnie Ty robisz taką opcję, że otwierasz transakcję, robisz selecta. Jak się, jak nie znalazłeś takiego rekordu, przy edycji, w sensie jak on nie jest wykorzystywany nigdzie indziej, to w tym momencie to zmieniasz. A jak jest wykorzystywany, to dajesz nowy wpis. Tylko teraz, żeby dowiedzieć się czy rekord był wykorzystywany musisz zrobić selecta, który będzie miał około 100 joinów.
Łukasz Kałużny: Jakbyś próbował w ten sposób zrobić, tak.
Szymon Warda: Bo musisz zrobić, tak, dokładnie. Więc w takim razie to nie zadziała, jak doskonale sobie zdajesz. 100 jointów to nie przeskaluje się.
Łukasz Kałużny: Nie, nie…
Co mi zrobisz jak mnie złapiesz: Ja to proszę Pana, mam bardzo dobre połączenia.
Łukasz Kałużny: Tym nie, jeżeli byś robił w ten sposób, szukał, to nie zadziała.
Szymon Warda: Tak, więc dochodzimy, dochodzimy do problemu, jest taki, że to się nie przeskaluje. Czyli mamy dwie opcje. Mamy opcję taką, że jeżeli mamy unikalne, to musimy robić joina, ponieważ tymi joinami wyłapujemy czy rekord jest wykorzystywany.
Łukasz Kałużny: Ale wytłumacz jeszcze po co jest ten join? Bo to dla niektórych może być…
Szymon Warda: Dlatego, ponieważ, jeżeli mamy taką sytuację, że mamy sobie te 100 encji, które wykorzystuje adres i łączy się do adresu, to stworzyliśmy bazę, która ma strukturę gwiaździstą. Czyli nasz adres jest taką, jest centrum, do którego wszyscy, wszyscy wchodzą, czyli mamy też sobie te joiny i musimy się do (…), żeby dowiedzieć się czy ten rekord jest wykorzystywany. A to musi być w transakcji, ponieważ musimy mieć…
Łukasz Kałużny: Wiesz co, rozrysujemy to, żebyście zobaczyli.
Szymon Warda: Może być.
Łukasz Kałużny: Ci co słuchają na Spotify, warto włączyć video. Ci co słuchają na innych, to warto przejść na YouTube’a i zerknąć.
Szymon Warda: Tak. No więc musimy się dowiedzieć. 100 jonów to jest dużo joinów. Tak trochę przydużo. Mamy też drugą opcję.
Łukasz Kałużny: Ale czemu wychodzisz, że 100 joinów?
Szymon Warda: Ponieważ, ponieważ skoro mamy 100 encji, które wykorzystuje adres, to musimy się dowiedzieć, czy adres jest gdziekolwiek wykorzystywany. Bo jeżeli adres byłby wykorzystany na na przykład placówce, a potem na paczce albo na portalu klienta, albo na czymkolwiek innym…
Łukasz Kałużny: Dobra, w ten sposób na to patrzysz, okej.
Szymon Warda: No tak…
Łukasz Kałużny: Dobra.
Szymon Warda: Tak rozumiem modelowanie.
Łukasz Kałużny: Dobra, że musisz wziąć i zupdate’ować ten wiersz, który…
Szymon Warda: Nie wiem gdzie on jest wykorzystywany. Mówiąc bardzo prosto, załóżmy ktoś nadaje na przykład paczkę na mój adres na przykład. Potem ja sobie wchodzę załóżmy w swój profil i zmieniam swój adres na Mozambik na przykład. No to paczka zaczyna nagle lecieć do Mozambiku. Potem zmieniam sobie na przykład na, powiedzmy, Stany Zjednoczone. No to nagle paczka leci do Stanów Zjednoczonych. Dlatego właśnie musimy upewnić się, czy nigdzie ten adres nie jest wykorzystywany. Więc mamy podejście, które się nie skaluje. Mamy teraz drugą opcję, którą też możemy zrobić, to, że w tabeli adresowej trzymamy unikalny, znaczy mamy, duplikujemy wiersze. Ale w tym momencie mamy bardzo, bardzo, bardzo długą tabelę. To Łukaszu co robimy?
Łukasz Kałużny: Partycjonujemy.
Szymon Warda: Po czym? Dobrze.
Łukasz Kałużny: W tym jedyne takie… Inaczej, jak teraz popatrzysz to jest partycjonowanie, to lecimy, jeżeli jest międzynarodowo, to najmniejszą, którą możesz zrobić od razu, to jest kraj, który masz słownikowe.
Szymon Warda: Dobrze.
Łukasz Kałużny: Bo rzuciłeś adres, że to nie jest tak. Więc to jest taka najmniejsza… Inaczej, to jest, bo przydałoby się, żebyś partycje umiał przewidzieć w tych danych.
Szymon Warda: Dobrze. Kraj względem kogo? Bo na przykład masz kraje Afryki, gdzie masz obszary, gdzie nie dogadasz się właściwie co jest. Kraje się łączą, kraje się dzielą i tak dalej, i tak dalej. Więc w tym momencie nagle wchodzimy w przerzucanie. Jestem wredna bestia, bo to pytanie ponownie znam i ono specjalnie pokazuje pewne problemy.
Łukasz Kałużny: Dobra, ale wiem do czego podchodzisz.
Szymon Warda: Wyolbrzymia bardzo mocno.
Łukasz Kałużny: Właśnie widzisz, bo wyolbrzymiasz teraz. Czy Ups działa na terenach wojennych? No nie Szymon, to jest też takie…
Szymon Warda: Ale nie chodzi. Załóżmy masz na przykład Somalia i Somaliland na przykład, no nie. Tereny, które są, oficjalnie jest terenem niezależnym, nieoficjalnie nie jest.
Łukasz Kałużny: Ale uważam, że to jest overengineering teraz w tym miejscu.
Szymon Warda: Czy ja wiem? Kraje się przesuwają, granice się przesuwają, są ruchome.
Łukasz Kałużny: Ruchome, ale wiesz, tylko pytanie czy w ogóle jakakolwiek cywilizowana firma świadczy tam usługi?
Szymon Warda: (…), że świadczy, ktoś świadczy. Łukasz, to jest wyolbrzymienie, ale…
Łukasz Kałużny: To jest bardzo mocne wyolbrzymienie.
Szymon Warda: Spokojnie, spokojnie, to jest modelowanie. Można znaleźć inne elementy, które tutaj się doczepisz. No więc mamy, więc po kraju, problematyczne bym powiedział.
Łukasz Kałużny: Ale jak pójdziesz dalej, to każda z nich jest problematyczna.
Szymon Warda: Oczywiście, że każda z nich jest problematyczna, tak,.
Łukasz Kałużny: Tak.
Szymon Warda: No więc co z tym zrobić fantem?
Łukasz Kałużny: No to opowiadaj, co zrobić?
Szymon Warda: Dobra, to teraz wróćmy sobie kawałek, właśnie na czym polega modelowanie? Modelowanie polega na tym głównie, żeby zrozumieć, jaki jest sens danej encji. Wszystkie podejścia na zasadzie generalnie miejmy adres unikalny albo miejmy adres zdublowany opierają się o tym, że możesz matematycznie określić, albo programistycznie, to samo, równość adresu. A stwierdziliśmy już, że nie możemy. Adres jest tym samym adresem tylko i wyłącznie w sytuacji, jeżeli kurier, pan listonosz może dostarczyć tą paczkę pod adres. Czyli dwa adresy, Aleja Jerzego Waszyngtona i Waszyngtona są tożsame, jeżeli paczka dotarła. Czyli adres nie ma pojęcia identyczności. Czyli załóżmy Ty, jako osoba, masz pojęcie w świecie rzeczywistym identyczności, masz swój PESEL, który uprośćmy, że jest unikalny, ale nie jest unikalny, taka ciekawostka.
Łukasz Kałużny: Były wtopy.
Szymon Warda: Było dużo wtop. Było naprawdę dużo wtop. Od dawna już nie ma tych wtop, ale generalnie były wtopy. Więc Ty masz swoje pojęcie unikalności.
Ślepnąć od świateł: Wiesz kim jestem? Wiesz.
Szymon Warda: Faktura ma swoje pojęcie unikalności, ponieważ ma swój numer. Banknot jako taki w teorii ma swoje pojęcie unikalności, ponieważ ma swój numer seryjny. Realnie w kontekście mikrosystemów nie jest ważne, tego zapisujemy sobie stan konta jako wpływ, odpływ i tak dalej, jako liczby. Skoro adres nie ma swojego pojęcia identyczności, to nie może istnieć jako tabela, bo ten nasz ID będzie sztuczny. Skoro będzie sztuczny, to nie możemy zrobić. Więc w takim razie co się w takiej sytuacji robi Łukaszu? Dowalasz te wszystkie kolumny adresowe do każdej encji niezależnie. Rozszerzasz tabelę.
Łukasz Kałużny: Czyli…
Szymon Warda: Nie masz tabeli adresowej.
Łukasz Kałużny: Ok, w ten sposób.
Szymon Warda: Tak. I dzięki temu zapewniasz sobie to, że teraz cały sharding robisz per encja, gdzie to powinno się znajdować i tam masz ten sens biznesowy. Faktury sobie dzielisz per firma i takie inne rzeczy, możesz sobie to ładnie zrobić. A adres nie istnieje, bo on nie jest, nie ma pojęcia identyczności. Swoją drogą jeszcze z takich ciekawostek, które były podczas, jak prowadziłem rekrutacje właśnie odnośnie tego, to było załóżmy: nie róbmy postaci normalnych. Ciekawostką to było właśnie jak ktoś na przykład próbował optymalizować to i na przykład osobną tabelą były województwa, to były miasta…
Łukasz Kałużny: Ja wiem, dlatego jak patrzysz, wiesz, zazdroszczę, bo jest ciekawy problem jak popatrzycie, poczytajcie sobie o rynku, w tym, o Irlandii, bo u nich przez długi czas adresem było obowiązującym imię, nazwisko, wieś i tam czwarty dom za kościołem po prawej stronie.
Szymon Warda: Ale to dalej funkcjonuje w Polsce. Jak masz takie małe wsie, to piszesz generalnie jaka wieś i tam pan listonosz wszystkich zna. Więc…
Łukasz Kałużny: Jest tak…
Szymon Warda: Jak pisałeś kartki do babci, to Twój adres nie był zbyt dokładny jak zakładam.
Łukasz Kałużny: Raczej wiesz, ale był kod pocztowy, po którym był routing. Pierwsza warstwa routingu zawsze jest robiona.
Szymon Warda: Tak, ale chodzi mi, że ostatnia mila to jest człowiek, który zna tych ludzi.
Łukasz Kałużny: Tak, dlatego tam liczę, że to się rozszerzy, to podejście, tam masz na wyspach masz Eircode na przykład, który zapisuje aż do drzwi adres.
Szymon Warda: Tak.
Łukasz Kałużny: Jest kod aż do drzwi.
Szymon Warda: Dobra, to ja mam propozycję taką jeszcze. To jest takie małe wyzwanie, bo to pytanie wielokrotnie prowadziłem. To pytanie czy ktoś z naszych słuchaczy ma inny pomysł na ogarnięcie tego tematu? Bo ja bardzo chętnie znalazłbym i wszedł w dyskusję, kto jak chciałby to zamodelować inaczej.
Łukasz Kałużny: Nie, bo wiesz, jak sobie popatrzysz, właśnie to jest problem, lokalnie, jak robimy na poziomie kraju, to jest proste, zaczyna być prostsze.
Szymon Warda: Prostsze, ale dalej masz, dalej masz nieproporcjonalnie długą tabelę. Bazy nie lubią długich tabel, bo tam masz B-drzewo. B-drzewo jest liczone od logarytmu swojej głębokości i tak dalej, i tak dalej, i tak dalej. (…), że to jest logarytm głębokości. A im głębsze drzewo, tym dużo mniej wydajny jest. Więc tam zaboli nas głównie indeks, który trzeba przebudowywać i tak dalej.
Łukasz Kałużny: Tak, stąd partycje i wiesz… To inaczej, tylko zaczynasz, mówisz o województwie i inne rzeczy, jesteś w stanie zrobić to do powiatu.
Szymon Warda: Województwa też się zmieniają i w Polsce się zmieniło województwo.
Łukasz Kałużny: Kiedy? Ostatnie… Słuchaj, wiesz, jak popatrzysz też wyolbrzymianie. Ostatnia zmiana, to co, 20…
Szymon Warda: 30 lat temu mniej więcej była.
Łukasz Kałużny: 30 lat temu, tak.
Szymon Warda: Tak Łukaszu, ale miasta się zmieniają, województwa się zmieniają.
Łukasz Kałużny: Nie, dlatego mówię, że miasto to jest bardzo zły wyznacznik. Województwo jest w miarę stabilną encją biznesową.
Szymon Warda: Można kombinować. Lokalnie to jest… To pytanie specjalnie jest wyolbrzymione. Oczywiście, że jest wyolbrzymione, dlatego, że ma pokazać pewne problemy. Modelowanie danych to jest umiejętność właśnie patrzenia na to, jak będziemy te dane wykorzystywali. Do czego one są, czy są do odczytu, czy są do zapisu, jak to widzimy? Najgorszym błędem, który ja często właśnie widzę, to są takie rzeczy, modelowanie na zasadzie: a to zróbmy sobie bardzo sztywny system na zasadzie słowników albo modelujemy świat rzeczywisty. Tylko żaden biznes nie operuje na świecie rzeczywistym, tylko operuje na tym, co potrzebuje ze świata rzeczywistego, upraszcza to.
Łukasz Kałużny: Modeluje na swojej domenie biznesowej.
Szymon Warda: Tak, a ta domena to jest właśnie sposobem patrzenia na świat w sposób uproszczony tego, co potrzebujemy. Tak że robienie tabelek, słowniczków i tak dalej, sorry, ale to się nie sprawdza.
Łukasz Kałużny: Trzeba będzie zrobić, tak moim zdaniem, dajcie znać w komentarzach, ale ja bym zrobił takie porównanie potem coś jeszcze bardziej noSQL-owego.
Szymon Warda: Możemy jeszcze, możemy jeszcze podziałać. Tutaj noSQL nam nie pomoże za bardzo.
Łukasz Kałużny: Nie, nie, bardziej pokazanie, bo wiesz, to co pokazałeś to jest wstęp i wytłumaczenie też. Bo zobacz, że pokazałeś zdenormalizowanie i potem jest jeszcze pojęcie, że rzeczy, które są, to jest chyba też mindfuck przy tym, że przykładowo jak modelujesz, weźmy moją ulubioną rzecz, czyli faktura.Bo zobacz, jeżeli joinujesz fakturę ze wszystkiego, tam wiesz, robisz, to jest raport, a nie faktura, która powinna być dokumentem, bo masz wizualizacja i raport versus stały dokument w bazie.
Szymon Warda: Czy, wchodzisz, masz, bo to jest fajnym przypadkiem, bo to zadanie jest też rozwinięciem na fakturę potem się dociąga, to jest to, że na przykład zmiana adresu powodowałoby zmianę danych na fakturze, co jest niezgodne z prawem.
Łukasz Kałużny: Bo powinieneś zrobić korektę. Stąd mówię właśnie…
Szymon Warda: Korektę, tak i faktura wystawiona jest, już powinna być niezmienna w Twoim systemie.
Łukasz Kałużny: Tak, stąd powiedziałem o tym dokumencie, bo to jest też. Trzeba znać fuckupy w domenie, w której pracujemy.
Szymon Warda: Limity, które powodują załóżmy, że w tym momencie adres nasz, mimo że powiedzmy może miałby coś, byłby niezmienny, to musimy odkładać zawsze kopie. Więc wtedy lepiej jak to się znajduje nie w tabeli, tylko osobnej, tylko w tej tabeli, w której to jest, bo w tym momencie dublujemy to.
Łukasz Kałużny: Dosłuchałeś do końca, więc chyba nie było źle, więc zostaw komentarz. Najlepiej 8 losowych słów oraz lajka pod tym odcinkiem.
Szymon Warda: Dobrze, tyle chyba.
Łukasz Kałużny: Tyle. Dajcie znać w komentarzach jak Wam się to podobało.
Szymon Warda: Dobrze. Trzymajcie się.
Łukasz Kałużny: Na razie. Hej!
