Wpis z mikrobloga

@thomekh: to prawda, ale należy pamiętać że w przypadku ssis projekty typu hurtownie danych nie są na tyle wielkie, by latami siedzieć na legacy systemach. Tym bardziej, że ssis dość łatwo migruje się do azure.

@lekkonieobecny: azure data factory jest dość podobne do ssis więc i tak łatwiej ci będzie się przerzucić. Generalnie wiele etl tooli jest do siebie podobnych. Niemniej kluczowe w tego typu rzeczach nie jest sklejenie sobie
@lekkonieobecny: @thomekh: @ostrykuc666: mi się ogólnie ssis podoba ale nie wiem jak narzędzie które jest jakieś 15 lat na rynku (m$ chyba je wykupił razem z firmą która je stworzyła) może być tak zbugowane i ciężkie w modyfikacji.
Błędy często nieczytelne. A zmiana w kolumnach lub gdzieś w przepływie wiąże się często z przeklikaniem albo usunięciem całej serii bloczków które idą dalej i wstawianiu ich ponownie
@obieq: SSIS powinien służyć tylko i wyłącznie przenoszeniu danych z jednego źródła do drugiego najlepiej bez żadnych modyfikacji, warunków czy obliczeń. Całościowo lub przyrostowo. Jeśli utrzymamy standardy to wtedy jest inna praca, bo możemy spokojnie operować na języku BIML ( XML + C# dla SSIS). Możemy mieć tysiące pakietów, kontenerów i zmieniać je wszystkie lub dostosowywać przy pomocy jednej instrukcji. Nie musimy nic klikać ani operować na GUI.
@thomekh: ok przy takim założeniu to spoko, ale większość to są chyba loop containery, lookupy, data conversion, juz nie mowie o derived columns i pozostalych ufnkcjach ktorych pewnie rzadko sie uzywa
@obieq: Wszystko jest kwestią jaką koncepcję sobie wymyślisz i jak to wdrożysz. Ja wyszedłem z założenia, że chcę pobierać dane jak najszybciej się da aby jak najszybciej produkcję zostawić w spokoju, nawet kiedy zasilanie odbywa się nocą. U mnie więc wygląda to tak, że z różnych źródeł pobieram tabele, słowniki i wrzucam je od razu do bazy (extract) po mojej stronie (klasyczny truncate + zasilenie, lub jak tabela jest duża to