Wpis z mikrobloga

@altknight1337: kilkaset... Ja kiedyś spotkałem się z raportami które miały kilka tysięcy, ale jak to jest jakoś uporządkowane (CTE) to idzie ogarnąć i w miarę prosto debugować.
  • Odpowiedz
@altknight1337 pakiety z procedurami i funkcjami potrafią mieć nawet kilkanaście lub kilkadziesiąt tysięcy linii. Jakieś super wielkie zapytania na kilkaset czy kilka tysięcy linii to widziałam w hurtowniach danych gdzie agreguja dane z kilku baz danych.
  • Odpowiedz
@Majkel2008: Jak jakiś mały bank i danych niedużo, to tak można się bawić. Już trochę siedzę w bankowości i jakby mielić dane samym SQL, to daleko się tak nie zajedzie. ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@Majkel2008: lepiej QueryDSLa zatrudnić, a potem on sklei w tle takiego SQLa nie na kilkaset linii tylko kilka tysięcy, którego nie będzie cało się przeczytać/optymalizować i nikt już więcej nie będzie chciał dotknąć tej części kodu xD

długie zapytania SQL to sól programowania, często jeszcze te zapytania są zoptymalizowane pod konkretne przypadki

ludzie mają optykę z projektów PetShop, gdzies zapytanie SQL to SELECT * FROM X WHERE X.foo = 'bar'
  • Odpowiedz
@altknight1337: poprzedni projekt - główne notebooki po 5k linijek kodu ;). Mix pysparka i sqla - raz pisane operacje w pysparku, raz w sqlu. Oczywiście inserty, selecty zwinięte żeby nie dokładać kolejnych linii.
Koszmar do debugowania, wynikało to z dużej rotacji ludzi ~srednia 3msc pracy ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@altknight1337: Zależy jak napisane. SQLe akurat szybko zjadają linijki przez specyficzne formatowanie i bardziej patrzyłbym na złożoność zapytań. A jak chodzi o procedury to normalka. Raz pracowałem z systemem, gdzie cała implementacja była w PLSQL na bazie a appka w Javie tylko forwardowała wywołania. Nawet były asynchronicznie procesy, kolejki zadań i generowanie PDFów na bazie xD
  • Odpowiedz