[Klaudia Kuszczak]

Cześć, dzięki za feedback do projektu. Bardzo go doceniam.❤

Przemku, masz rację co do relacji: u mnie jest 1:1, więc nie ma czego sklejać z kilku kolumn. Mój jedyny argument za surogatem nie wynika z zasad modelowania, lecz z warstwy serwującej. Model trafia do Power BI, a tam w VertiPaq relacje po intach są tańsze niż po tekście. Przy Direct Lake nie jestem pewna, ile z tego zysku zostaje, więc zamiast bronić tego teoretycznie, po prostu zmierzę obie wersje po migracji.

Marku, dzięki za przestawienie tego na pytanie o wymaganie biznesowe zamiast o poprawność modelu. Odpowiedź brzmi „nie”. Nic dalej nie potrzebuje wiedzieć, które wiersze wymiaru są nowe. Nadpisywanie kilkudziesięciu wierszy zostaje, a CDF zapisuję sobie na moment, gdy faktycznie pojawi się taka potrzeba.

Za swój faktyczny błąd uznaję nie samo użycie klucza surogatowego, tylko sposób jego generowania. row_number() daje wartość zależną od zawartości tabeli w danym przebiegu, więc przy ładowaniu przyrostowym klucze by się rozjechały. Jeśli surogat zostanie, to tylko liczony deterministycznie, tak jak zrobiłam to od początku w wymiarze daty, gdzie klucz jest wyprowadzony bezpośrednio z wartości.

Po przemyśleniach schodzę do INNER JOIN-a, a wiersze bez pary będą lądowały w osobnej tabeli błędów i dzięki temu job poleci dalej, a anomalia będzie policzalna, zamiast rozpływać się w NULL-ach.

Podpowiedź o Volumes jest dla mnie najciekawsza, bo zdejmuje cały problem, z którym walczyłam w Fabricu i zamiast pilnować ścieżek w kodzie, przepina się źródło pod stałą nazwą. To realnie upraszcza plan migracji.

Wrócę z wynikami, jak przepiszę projekt na Databricks.

😀