Summary
Modelowanie danych w kontekście systemów informatycznych staje się kluczowym tematem, zwłaszcza w przypadku firm kurierskich, gdzie precyzyjne zarządzanie adresami jest niezbędne. W rozmowie poruszane są wyzwania związane z unikalnością i duplikacją adresów, które mogą występować w różnych kontekstach, takich jak paczki, faktury czy profile użytkowników. Ekspert podkreśla, że żaden biznes nie operuje w idealnym świecie rzeczywistym, lecz w rzeczywistości, która wymaga uproszczeń i dostosowań do specyficznych potrzeb.
Dyskusja koncentruje się na problemach związanych z aktualizacją adresów, które mogą być wykorzystywane w wielu miejscach jednocześnie. W przypadku zmiany adresu przez użytkownika, konieczne jest uwzględnienie, czy dany adres jest już przypisany do innych encji, co może prowadzić do skomplikowanych operacji w bazach danych. Ekspert sugeruje, że w celu efektywnego modelowania danych, warto unikać sztywnych struktur i zamiast tego skupić się na elastyczności oraz dostosowaniu do specyficznych wymagań biznesowych.
W kontekście modelowania danych, omawiane są również różne podejścia do zarządzania adresami, w tym możliwość de-normalizacji danych, co może uprościć operacje na bazach danych. Wskazano na konieczność zrozumienia, że adresy nie mają jednoznacznej identyfikacji, co komplikuje ich modelowanie. Ekspert zachęca do dyskusji na temat alternatywnych metod modelowania, podkreślając, że kluczowe jest zrozumienie kontekstu biznesowego, w którym dane są wykorzystywane.
Show Notes
"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? ⚠️ A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:01:13 Pytanie rekrutacyjne: system dla firmy kurierskiej 00:02:37 Jedna tabela adresów i problem duplikatów 00:04:32 Zamówienia, historia paczki i poprawki adresu 00:07:20 Unikalność i porównywanie adresów 00:09:59 Joiny i struktura gwiaździsta 00:11:56 Duplikowanie wierszy i partycjonowanie 00:14:29 Adres bez tożsamości – kolumny adresowe w encjach 00:16:16 Ciekawostki z rekrutacji i adresy w Irlandii 00:17:50 Wyzwanie dla słuchaczy, długie tabele i partycje 00:19:06 Czym jest modelowanie danych 00:21:16 Zakończenie
More from Patoarchitekci
"Dla mnie łyknął za dużo AI-owego LSD." 🎯 Tak Łukasz podsumowuje keynote DHH na RailsConf. Szymon broni prezentacji, bo jego zdaniem wycinki z Twittera wypaczyły jej sens: Rust tylko w core, Ruby on Rails dalej w aplikacjach webowych, a natywne apki zamiast uniwersalnych, bo ich utrzymanie to dziś po prostu koszt tokenów. Spór szybko schodzi głębiej. Łukasz przypomina, że Agile skończył jako SAFe, a DevOps jako stanowisko, i AI czeka ten sam los. Szymon odpowiada: "Pilnowanie staje się wartością, myślenie staje się wartością". Kontrargument Łukasza z życia klienta: "dwa miesiące przepisywania systemu automatami i dwa miesiące backfixowania jebanego". ⚠️ Dalej linki. Vector Search wszedł w GA w SQL Server, a Łukasz zbudował na nim hybrid search do MCP Pato, bo "nie mam tam żadnej bazy wektorowej". Do tego Meta i Microsoft przycinają limity w Anthropic, który szuka Mega Account Executive za 450 tysięcy dolarów rocznie. Na deser Decision API: Jev, Clef od Cloudflare, 10 centów za milion tokenów wejściowych i odpowiedź poniżej 100 ms. Brand24 ma 92% trafności, a Jev 88%. Czy klasyfikator budowany latami przetrwa jeszcze rok? A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:02:24 Vector Search w SQL i uniwersalność baz relacyjnych 00:04:11 Keynote DHH na RailsConf, Hashimoto i przepisywanie na Rusta 00:10:37 Frameworki, korporacyjne mielenie rewolucji i powrót aplikacji natywnych 00:13:19 Możliwości i ograniczenia AI: halucynacje, nowe odkrycia i entuzjazm 00:16:57 Biznes wokół AI: własne klastry GPU, chińskie modele i limity w Anthropicu 00:20:02 Decision API: Jev, alternatywy, koszty i zastosowania 00:26:13 Podsumowanie i zakończenie
"Czyli ten taki element, który wszyscy traktują: eee tam, pitu pitu, a okazuje się, że jest jednym z najbardziej krytycznych." 🎯 Szymon przyniósł 16 stron notatek o OpenTelemetry Collector. Każda strona to osobny sposób na zgubienie telemetrii. Budujemy topologię kolektorów od zera. Collector per namespace, DaemonSet na wypadek aplikacji, która nie wstała, i agenci na VM-kach zamiast otwierania sieci dla Prometheusa. Nad tym OTel Gateway, który ma być "głupi jak budowa cepa", a nie kolejnym ESB. Do tego Kafka przed Lokim i gRPC, które za load balancerem po cichu sabotuje skalowanie. Potem ciche awarie. Błąd w konfiguracji? Kolektory "zrobią rollback do poprzedniej wersji, Ty się o tym nie dowiesz". Unauthorized nie jest retry'owany, więc dane lecą do kosza. ⚠️ Recepta Szymona: "metryki, metryki, metryki". Na deser tail sampling, który według Szymona "niewyobrażalnie komplikuje architekturę całego rozwiązania". Chyba że masz terabajty trace'ów w trzy dni. Czy Grafana Alloy to obowiązek, czy kolejna warstwa, na której się wywalisz? A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:01:21 Podstawy: observability, OpenTelemetry i sygnały 00:04:36 Topologia kolektorów: Kubernetes, maszyny wirtualne, push i pull 00:10:08 Niezawodność dostarczania: kolejki, bufory i Kafka 00:13:39 Load balancing kolektorów i gRPC 00:15:02 Monitorowanie kolektorów i błędy konfiguracji 00:17:24 Architektura wewnętrzna kolektora i niezależność od dostawcy 00:18:58 Logowanie z aplikacji: OTLP, stdout i aplikacje zewnętrzne 00:22:45 Sampling, retencja i koszty trace'ów 00:27:38 Podsumowanie: kiedy wdrażać kolektor 00:28:29 Zakończenie
"Czekaj, otrzymujesz 6 plików." 🎯 Tyle kosztuje jedna poprawka buga w GitHub Spec Kit, jeśli bierzesz go dosłownie. Bierzemy na warsztat spec-driven development, czyli generowanie kodu z UML-a w nowym wydaniu: agenci AI zamiast generatorów, Markdown zamiast diagramów. Idziemy krok po kroku. Constitution: zasady projektu czy lista życzeń? Clarify to według Szymona "chomąto na człowieka w postaci speckita". Pliki tasków w repo mają wartość "okrągłe zero. Nawet może przepraszam, pomyliłem się ujemna". Łukasz dorzuca swoje: zbiór Markdownów bez hooków i skryptów to nie jest harness dla agentów. ⚠️ Potem robi się gęsto. Łukasz traktuje specyfikacje jak ADR-y i chce "wychłostać agenta za próbę zmiany czegoś w starych specyfikacjach". Szymon ripostuje o projekcie żyjącym 5 lat: "Dosłownie umrzesz od nich." Do tego spór o C4, waterfall jako spychologia i model Fable, który chciał wyciąć 70% skilli. 🤖 Czy specyfikacja jako źródło prawdy to mit, skoro na końcu i tak wygrywa kod? A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:02:02 Geneza i założenia Spec Driven Development oraz przegląd podejść 00:06:25 GitHub Spec Kit: instalacja, konstytucja i brak hooków 00:09:13 Kroki Specify i Clarify: kontekst zadania i doprecyzowanie 00:10:57 Kroki Plan, Tasks i Analyze: planowanie, testy i review 00:16:52 Implementacja, warianty workflow i podejście Anthropic 00:19:46 Kiedy SDD ma sens: zespół, human in the loop i rozmiar zadania 00:23:56 Specyfikacje a dokumentacja: ADR-y, C4, źródła prawdy i harnessy 00:29:04 Czy SDD to powrót do Waterfalla i sprzątanie artefaktów 00:33:23 Przyszłość specyfikacji przy coraz mądrzejszych modelach 00:35:53 Podsumowanie: Spec Kit jako narzędzie do strukturyzacji myślenia 00:36:08 Polecane materiały i odcinek o Open Mercato 00:37:01 Zakończenie i zaproszenie do komentarzy
"Jeżeli chodzi o architekturę, nie pozwalam mu podejmować żadnych decyzji." 🎯 Łukasz stawia granicę, a Szymon kontruje: "pozwólmy tym agentom robić ten kod, który jest krótkowzroczny" - i raz na pięć iteracji każmy zrobić refactor. Przechodzimy SDLC z AI fazę po fazie, od zbierania wymagań do życia po deployu. Na wejściu AI tylko wspomaga - "nie pójdzie do legala, do procurementu" i nie odsiedzi dupogodzin na spotkaniach. Dalej: linki do chatów od biznesu zamiast przepakowanych wymagań, powrót Enterprise Architecta i YAML jako formalny output specyfikacji. Plus prototypy klikane przez biznes, których nie negujesz - ale kod i tak idzie do kosza. ⚠️ Potem twarda część: harness to nie pliki MD, tylko hooki, lintery i SonarQube, których agent nie ominie. Frontend przechodzi testy - OK, skasujesz i wygenerujesz na nowo. Logika biznesowa - review. Agent SRE na read only halucynuje, a z pełnymi uprawnieniami stwierdzi, że "buga nie będzie jak będzie baza pusta". 🤖 Na deser koszty tokenów (150-300 dolarów na DevOpsa, od 300 na developera), mBankowe 3-4% wpływu AI na cały proces i złośliwa puenta: "Jakbyś miał dobry proces, to byłeś już gotowy." Kto definiuje good enough - Ty czy agent? A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:01:44 Zbieranie wymagań: kontekst, chaty od biznesu i formalny output 00:10:47 PoC i MVP budowane przez biznes — jak na to reagować 00:12:33 Faza projektu: krótkowzroczny kod agenta i long term maintainable code 00:15:11 Przygotowanie środowiska pracy, harness i workflow zespołu 00:18:30 Dekompozycja na zadania, architektura, granice i good enough 00:23:44 Wytwarzanie: skala szarości, frontend, logika biznesowa i frameworki 00:31:05 Ownership kodu, odpowiedzialność za outcome i myślenie holistyczne 00:34:24 Dostarczanie i życie po deployu: release'y, agenci SRE, halucynacje 00:40:32 Utrzymanie i ewolucja: aktualizacje, martwy kod i decommissioning 00:42:30 Mity, koszty tokenów i dobry proces jako gotowość na agentów 00:45:34 Podsumowanie i zakończenie
"To jest świetne, że load balancer nie load balansuje." 🎯 Łukasz otwiera odcinek o sieciach, o których zapomnieliście po studiach - a Szymon przyznaje wprost: "Starałem się to wyprzeć i stwierdziłem, że nigdy mi się nie przyda. Byłem w błędzie." Zaczynamy od modelu OSI, z którego realnie widzisz dwie warstwy, i od brutalnej prawdy o pingu: "Jak działa, to fajnie, niewiele mówi, ale jak nie działa, to nam tak dużo znowu nie mówi." Potem QUIC i HTTP/3, które w korporacji i tak wycinacie na UDP/443, bo Palo Alto i Zscaler tracą SNI do reguł. Ciekawostka: w Korei Południowej QUIC przyspieszył Chrome'a na Androidzie o całe 1,3%. ⚠️ Dalej klasyka gatunku - DNS. Warstwy cache'u, w których ipconfig /flushdns nic nie da, TTL nadpisywany do godziny, ndots w CoreDNS, Alpine bez DNS po TCP i limit 1000 requestów na sekundę na chmurowym resolverze. Plus Azure private endpoint, który po cichu wypuszcza ruch publicznie, bo brakuje jednego CNAME. Na deser wyczerpanie portów SNAT (1024 porty na węzeł), WCF, który zabijał aplikację w 5 minut, i idle timeouty ubijające połączenia bez słowa: "Klient trzymający połączenie się często nie dowie, że zostało zerwane." 🤖 Sprawdź, czy Twoje skalowanie faktycznie skaluje - zanim zrobi to za Ciebie produkcja. A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro 00:01:33 Model OSI — siedem warstw, z których widać dwie 00:03:18 Diagnostyka sieci — ping to nie wszystko, ICMP i tooling 00:05:56 TCP vs UDP, Quic i HTTP/3 — także w korporacji 00:10:14 DNS — mity, cache, TTL i przełączanie ruchu 00:15:07 DNS w Kubernetesie i w chmurze — ndots, limity, private endpoint 00:21:07 Routing w chmurze — ukryte routery i MTU 00:22:22 Porty źródłowe, SNAT, egress i długo żyjące połączenia 00:26:39 Load balancer, który nie load balansuje, i sticky sessions 00:28:59 Podsumowanie i checklista do sprawdzenia