Od stabilnej relacji po nową architekturę danych
W zarządzaniu bazą danych często zaczyna się „zwyczajnie”: od tabel, kluczy i kilku procedur, a kończy na pytaniach o skalę, niezawodność i to, czy model danych nadal trzyma się w ryzach. Dlatego obok fundamentów projektowania relacyjnych baz danych coraz częściej pojawiają się rozmowy o hurtowniach, podejściu domenowym i o tym, jak łączyć różne style pracy z danymi bez chaosu.
Jeśli chcesz zobaczyć, jak te dylematy wyglądają w praktyce administracyjnej, SQL Server. 100 najczęstszych błędów i jak ich skutecznie unikać Petera A. Cartera dobrze porządkuje typowe sytuacje: wolne T-SQL, brak właściwych danych do diagnozy czy ryzykowne ustawienia, które potrafią zaboleć dopiero na produkcji.
Projektowanie relacyjne, które wytrzymuje życie na produkcji
Wiele problemów z wydajnością i utrzymaniem nie bierze się z „magii silnika”, tylko z projektu: zbyt luźnych zależności, niejasnych encji, niefortunnych ograniczeń albo ich braku. I tu przydaje się podejście bardziej obrazowe, krok po kroku, szczególnie gdy pracujesz jako analityk, developer lub admin i musisz dogadać się z biznesem co do tego, czym właściwie jest rekord i jak długo ma żyć.
W tym duchu Relacyjne bazy danych. Ilustrowany przewodnik Qianga Hao i Michaila Tsikerdekisa pomaga rozplątać złożone tematy projektowe tak, by łatwiej było uniknąć kosztownego „przerabiania wszystkiego od nowa” po wdrożeniu.
Hurtownia, data lakehouse i data fabric w realnych decyzjach zespołu
Gdy dane zaczynają płynąć z wielu systemów, a zespół potrzebuje spójnych definicji i przewidywalnego dostępu, pojawiają się opcje wykraczające poza klasyczne OLTP. W praktyce oznacza to wybór między podejściami typu hurtownia danych, data lakehouse, data fabric czy siatka danych — i (co ważne) odróżnianie faktów od marketingowych skrótów myślowych, bo to tu łatwo o nietrafiony projekt.
Nowoczesne architektury danych. Przewodnik po hurtowni danych, siatce danych oraz Data Fabric i Data Lakehouse Jamesa Serry prowadzi przez mocne i słabe strony tych koncepcji w sposób, który przydaje się przy planowaniu kierunku dla platformy danych, nawet gdy wymagania zmieniają się w połowie kwartału.
Ta kategoria jest też wygodnym mostem między rolami: od administratora dbającego o stabilność i bezpieczeństwo, przez inżyniera danych projektującego przepływy, po architekta, który musi „spiąć” domeny i standardy. A jeśli chcesz wejść głębiej w pracę z tekstem i danymi nieustrukturyzowanymi, naturalnym kolejnym krokiem bywa podkategoria NLP.
